Acerca de
Sobre mí
Soy Luiz Claudio Hogrefe, arquitecto de software y vivo en Colonia.
Publico como Luiz Hogrefe. Desarrollo software desde 2008, primero en Brasil y, desde 2014, en Alemania. La mayor parte de esos años transcurrió en proyectos empresariales en los que una arquitectura tiene que sobrevivir a auditorías, sistemas heredados y traspasos, no solo a una primera versión.
Hoy mi trabajo se sitúa donde la arquitectura de software se encuentra con la IA gobernada, la interoperabilidad semántica y la evidencia digital trazable. Me importa menos lo que un sistema puede hacer en una demostración que lo que se niega a hacer, lo que puede probar después y quién tiene permiso para cambiarlo.
Cómo llegué hasta aquí
Empecé en 2008 como programador en Edusoft, en Blumenau, trabajando en las rutinas financieras y académicas de un sistema web de gestión académica. En la FURB, la universidad regional, trabajé como desarrollador de software y más tarde como analista de sistemas, y allí terminé mi grado en Ciencias de la Computación. Mi tesis de grado aplicaba ontologías al desarrollo de sistemas de información en un entorno de computación en la nube, un tema que sigue presente en mi trabajo sobre semántica.
En 2014 me mudé a Alemania. Tras unas prácticas de desarrollo en Java en Berlín y un puesto de desarrollador de software en un proveedor de nube privada en Düsseldorf, trabajé de forma independiente en aplicaciones web y móviles.
De 2017 a 2022 fui consultor en Sopra Steria, en proyectos para clientes de los sectores de energía, banca y automoción. El trabajo abarcaba desde el desarrollo de aplicaciones web hasta la arquitectura y la documentación de una plataforma de orquestación y conceptos de despliegue. Tras un año en Brasil en la dirección interina de una empresa familiar, volví a la consultoría en msg, en Colonia, como desarrollador, Scrum Master y responsable de pruebas.
En 2024 comencé una investigación independiente sobre interoperabilidad semántica, pasaportes digitales de producto y las normas europeas que los exigirán. En 2025 trabajé en Accenture en ingeniería de calidad, como Scrum Master y tester en un programa empresarial. De agosto de 2025 a abril de 2026 diseñé la arquitectura de AnyImob, un asistente de IA para la intermediación inmobiliaria, y dirigí su desarrollo. De mayo a agosto de 2026 fui arquitecto de software en la división de Estándares de IW Consult, en Colonia, donde trabajé en la arquitectura y los modelos de datos de pasaportes digitales de producto y en ECLASS como semántica para gemelos digitales.
Desde septiembre de 2026 desarrollo mi investigación de forma independiente a través de AnyLAI, un proyecto de I+D no comercial.
Cómo entiendo la arquitectura
Para mí, la arquitectura es el conjunto de decisiones que resultan caras de revertir, puestas por escrito donde puedan comprobarse. Un diagrama ayuda. Una frontera que el pipeline de compilación hace cumplir ayuda más.
En entornos regulados esto se vuelve concreto. Un requisito del ESPR, el EUDR o el AI Act no es una etiqueta que se le pone a un sistema a posteriori. Es una entrada, como la latencia o el volumen de datos, y tiene que reflejarse en los modelos de datos, las interfaces, los pasos de revisión y la evidencia que conserva un sistema.
Los modelos de IA capaces cambian el lugar donde está el trabajo difícil. Cuando la implementación se abarata, la intención, las restricciones y la verificación ganan valor. Esa es la tesis en la que trabajo ahora.
Cómo trabajo
Cinco principios que aplico a mi propio trabajo. Son hábitos de ingeniería, no leyes de la naturaleza.
- 01
Arquitectura antes que eslóganes
Un sistema se describe por sus fronteras, sus interfaces y lo que se niega a hacer. Una afirmación que no puede vincularse a ninguna de esas tres cosas todavía no es arquitectura.
- 02
Fronteras deterministas alrededor de sistemas probabilísticos
Los modelos son útiles y falibles. Hacen un trabajo acotado detrás de reglas que deciden, dejan registro y pueden reproducirse, y nunca son el origen de un permiso.
- 03
Evidencia que otra persona puede verificar
Un resultado vale lo que un lector puede comprobar sin confiar en su autor. Sus fuentes, su versión y la persona responsable viajan con él.
- 04
Estándares sin dependencia de proveedor
Primero los estándares públicos, como W3C Verifiable Credentials, UN/CEFACT y GS1, para que lo que construyo pueda comprobarse, sustituirse o traspasarse sin mí.
- 05
Hacer explícita la ambigüedad antes de automatizarla
La automatización amplifica todo lo que recibe. Un requisito ambiguo se convierte en un error sistemático, así que primero pongo la ambigüedad por escrito y la resuelvo con las personas a las que corresponde.
Idiomas
Trabajo en cuatro idiomas, y esa es también la razón por la que este sitio existe en cuatro.
- Portuguésnativo
- AlemánC1
- InglésC1
- Españolcompetencia profesional para el trabajo
Investigación actual
Mi investigación se desarrolla y se publica a través de AnyLAI, un proyecto de I+D independiente y no comercial. No es una empresa, y nada de lo que publica es una oferta.
Hasta ahora incluye COADF, un marco publicado para construir software asistido por IA bajo una gobernanza explícita; ERQYO, una arquitectura de ejecución para decisiones gobernadas, con una implementación de referencia; y AnyDPP, un entorno de investigación para pasaportes digitales de producto basados en evidencia.