Cliente. Un operador que transporta personal a yacimientos petrolíferos y mineros en Vaca Muerta y Mendoza: cientos de vehículos, contratos por yacimiento, y un costo de combustible y de riesgo que se mide por kilómetro recorrido en rutas exigentes.
Enfoque
Este caso recorre tres eslabones del método —sociología de las organizaciones, ingeniería de software e ingeniería de datos— sin handoffs entre ellos: la misma lectura que ordenó qué significa un viaje, un costo o un evento de riesgo en esta empresa es la que después modeló el dato y construyó las herramientas. El cuarto eslabón —la IA sobre el dato— queda fuera del alcance entregado: acá la inteligencia se aplica como instrumento de trabajo del ingeniero, no como producto. La distinción es deliberada y es parte de la honestidad de la marca.
La tesis que gobierna el trabajo es la de la calidad de datos contextual: un dato de flota técnicamente correcto puede igual mentir si se lo lee fuera del proceso humano que lo produjo. Una patente no es una clave estable; un chofer no es un identificador único entre sistemas; un “viaje” en operación no es la misma unidad que un “viaje” en costos. Modelar primero el significado, y recién después la tabla, es lo que separa una plataforma de datos de un almacén de errores más rápido.
El problema detectado
La empresa gobernaba su flota con planillas dispersas: la operación vivía en un sistema, el riesgo y la telemática en otro, los costos e ingresos en SAP, y el maestro de vehículos y contratos en un tercer lado. Nadie podía responder, con una sola consulta confiable, la pregunta que importa al negocio: ¿este vehículo, en este periodo y bajo este contrato, gana o pierde plata, y con qué nivel de riesgo opera?
El problema declarado era “queremos un tablero”. El problema real era anterior: no existía una llave común que permitiera cruzar las fuentes sin degradar el significado en cada empalme. Sin esa columna vertebral, cualquier tablero hubiera sido un promedio de datos que no hablan el mismo idioma.
Relevamiento funcional
Mapeé seis capas de fuente y, para cada una, qué dice de verdad —no qué dice el manual—:
| Fuente | Qué aporta | Unidad de análisis |
|---|---|---|
| Operación | Vueltas, kilómetros, combustible, puntualidad | viaje / vehículo |
| Telemática de riesgo | Eventos, ranking, score de conducción, ADAS, posiciones | evento / vehículo |
| SAP (S/4HANA + BTP + CPI) | Costos, ingresos, centros de costo | documento contable / CeCo |
| Parque móvil | Maestro: patente ↔ interno ↔ centro de costo ↔ contrato | vehículo |
| Comercial | Cliente y contrato | contrato |
| Personas / choferes | Homologación multi-fuente de conductores | persona |
El relevamiento incluyó un análisis de brechas explícito: por ejemplo, la API de posiciones de la plataforma de telemática no exponía el ranking ni el ADAS, lo que obligó a escalar con el proveedor en lugar de asumir que el dato estaba disponible. Documentar lo que no se puede obtener es tan parte del relevamiento como documentar lo que sí.
Construcción de la solución técnica
La pieza central no es un pipeline: es una llave de integración canónica —patente_normalizada + periodo + asignación vigente— que permite cruzar las seis fuentes sin perder el significado en los empalmes. Sobre esa llave diseñé un modelo dimensional:
- Dimensiones
dim_cliente,dim_contrato,dim_centro_costo. - Un hecho
fact_asignacion_vehiculoversionado en el tiempo, porque un vehículo cambia de contrato y de centro de costo, y el cruce de costos contra operación tiene que respetar qué asignación estaba vigente en cada periodo.
El modelo se documentó como fuente de verdad —modelo conceptual, modelo de datos canónico, glosario de negocio, roadmap por fuente y un registro vivo de preguntas abiertas—, de modo que la decisión de diseño quede auditable y no en la cabeza de una persona.
Frente al MVP que el cliente construía en paralelo sobre un lakehouse, posicioné el modelo objetivo de forma explícita: no como competencia, sino como la capa de significado que cualquier herramienta analítica necesita por debajo para no producir tableros que mienten.
Capa de información y datos
El gobierno del dato fue diseño, no anexo. Tres frentes:
- Calidad y trazabilidad. Cada métrica de negocio puede rastrearse hasta su fuente y su definición; el glosario fija qué significa cada término antes de que se calcule.
- Identidad y cumplimiento. Identifiqué un riesgo de identidad de chofer —la homologación multi-fuente de personas— con impacto directo en auditoría, encuadrado en la Ley 25.326 de protección de datos personales. Un cruce mal resuelto acá no es un bug: es un pasivo regulatorio.
- Comunicación ejecutiva. El estado del modelo se sostuvo con informes de avance y memorias de reunión para los stakeholders, de modo que las decisiones de datos fueran legibles también para quien no lee SQL.
Cómo se condujo el trabajo
El trabajo se ejecutó con un harness de agentes de código (Claude Code) gobernado por instrumentos propios, no por prompting improvisado. Lo concreto y verificable:
- Dos servidores MCP propios, en Python, que exponen el dominio a los agentes:
- uno para el sistema de operación de flota (assets, planilla de vueltas, informe de combustible, request genérico), con mapeo al modelo canónico;
- uno para la API de posiciones de la plataforma de telemática (vehículos, conteo de kilómetros, resumen diario, última posición), con autenticación OAuth2 ROPC sobre Azure B2C y un smoke test por CLI.
- Cada servidor lleva su spec OpenAPI versionada en el repo y un modo degradado sin credenciales: el agente puede razonar sobre la forma de la API aun sin acceso productivo. Esto es gobierno por capas aplicado a la herramienta —el agente accede al contrato del dato, no al secreto.
- La documentación del dominio (modelo canónico, glosario, relevamientos) se expone también vía MCP, de modo que el agente trabaja contra la fuente de verdad versionada y no contra su memoria.
- Las tareas repetitivas del relevamiento —consultar una API, contrastar su respuesta contra el modelo, registrar una brecha— se vuelven workflows reproducibles sobre estas herramientas, en lugar de pasos manuales que se degradan con el cansancio.
El punto: la IA no está en el producto entregado al cliente; está en cómo construyo, como cualquier ingeniero serio usa hoy su instrumental. Mostrarlo así —factual, sin adjetivos— es lo que distingue el dominio real de la herramienta del discurso de moda.
Qué prueba este caso
- Data engineering de verdad: un modelo canónico multi-fuente con una llave que preserva el significado, no un esquema dibujado de memoria.
- Desarrollo con disciplina de entorno regulado: dos MCP reales, con specs y tests, no una mención genérica de “uso IA”.
- Lectura sociotécnica: el riesgo de identidad de chofer y la Ley 25.326 se detectaron leyendo el proceso humano detrás del dato, no auditando el código.