¿Está preparada tu arquitectura de datos para llevar la IA a producción?

No necesita acceder a todos los datos de la organización, pero sí a todos los que exige el proceso que va a ejecutar. Parece una distinción evidente, aunque en producción puede implicar conectarse simultáneamente a CRM, ERP, documentación interna, bases operacionales, repositorios cloud o información almacenada en sistemas heredados.

El primer ejercicio consiste en enumerar esas fuentes y comprobar cuáles son realmente accesibles desde el entorno de ejecución, con qué permisos, qué latencia presentan y con qué frecuencia se actualizan. Una integración que exige exportaciones manuales o copias periódicas puede ser suficiente para una demostración, pero convertirse en una debilidad cuando el sistema debe tomar decisiones utilizando información actualizada.

Catalogar un dato no significa necesariamente gobernarlo. Cuando la IA empieza a utilizar información distribuida, lo importante es comprobar si siguen aplicándose de forma coherente las reglas sobre identidad, permisos, clasificación, privacidad y uso permitido, independientemente de la aplicación o infraestructura desde la que se acceda.

La prueba puede realizarse sobre el perímetro mínimo del caso de uso. Cada conjunto de datos relevante debería tener un responsable, una clasificación conocida, políticas de acceso y suficiente información sobre su procedencia. Esta cuestión adquiere todavía más importancia con los agentes, porque ya no se limitan a recuperar información: pueden combinar diferentes fuentes y utilizar el resultado para desencadenar acciones posteriores.

Mover información suele ser una solución rápida durante las primeras fases de un proyecto. En producción, cada nueva copia introduce almacenamiento, sincronización, transferencia, controles de seguridad y otra versión del dato que debe mantenerse actualizada.

La pregunta ya no debería ser simplemente si técnicamente podemos trasladar los datos, sino si necesitamos hacerlo. Tecnologías de consulta federada, formatos abiertos y arquitecturas lakehouse permiten acceder a determinadas fuentes sin crear necesariamente otra copia completa. Cloudera, por ejemplo, está utilizando Trino para acceso federado y Apache Iceberg y Polaris para facilitar interoperabilidad y acceso gobernado entre diferentes motores.

Esto conecta con una decisión arquitectónica más amplia: en determinados casos puede resultar más eficiente acercar el procesamiento y la IA al lugar donde reside la información en vez de trasladar sistemáticamente el dato hacia una plataforma central.

El coste de una aplicación de IA no termina en el precio del modelo ni en el número de tokens utilizados. Una petición puede activar búsquedas, consultas a bases de datos, llamadas a APIs, inferencias adicionales, almacenamiento, comunicaciones entre agentes y recursos de CPU o GPU.

Esto hace que una métrica aparentemente sencilla, como el coste por millón de tokens, diga poco sobre la economía real de un proceso. Resulta más útil conocer cuánto cuesta resolver una incidencia, analizar un contrato, procesar una solicitud o completar cualquier otra tarea de negocio.

El problema está empezando a afectar a las decisiones arquitectónicas. En un estudio publicado por Cloudera en octubre de 2026, el 89% de las organizaciones encuestadas afirmó haber limitado o rediseñado casos de uso ante el aumento del consumo de tokens.

Una respuesta final no es suficiente cuando un sistema participa en un proceso empresarial. Si se produce un error, una decisión inesperada o un incidente de seguridad, la organización debería poder reconstruir qué información se consultó, qué versión del modelo intervino, qué herramientas utilizó el sistema y qué acciones ejecutó.

La trazabilidad deja así de ser una cuestión vinculada exclusivamente al cumplimiento normativo. También es una capacidad operativa: permite diagnosticar errores, comparar versiones, investigar incidentes y entender por qué cambia el comportamiento del sistema.

El AI Act europeo refuerza esta dirección para determinadas categorías de sistemas de alto riesgo, que deben permitir el registro automático de eventos durante su funcionamiento. En arquitecturas agénticas, donde una única tarea puede incluir múltiples pasos y herramientas, esa observabilidad se vuelve todavía más relevante.

Hablar de soberanía únicamente en términos de residencia del dato ofrece una visión incompleta. Una aplicación de IA moderna puede utilizar modelos externos, bases vectoriales, memorias, APIs, servicios de inferencia y sistemas de observabilidad alojados en lugares diferentes.

Conviene por tanto dibujar el recorrido completo de una interacción. ¿Dónde se encuentra la información original? ¿Dónde se realiza la inferencia? ¿Se envía parte del contenido a un tercero? ¿Dónde quedan almacenados prompts, resultados, memoria y logs? ¿Qué jurisdicción se aplica a cada componente?

La localización también puede ser una decisión económica y operativa. Cloudera sitúa esta flexibilidad en el centro de su estrategia "AI Anywhere": ejecutar IA donde residen los datos, ya sea en nube pública, infraestructura privada o edge, manteniendo una capa común de gobierno y control.

Esta pregunta prácticamente no existía en las primeras aplicaciones empresariales de IA generativa. Un agente cambia el escenario porque puede utilizar herramientas, consultar diferentes sistemas, decidir entre varias acciones y actuar con cierto grado de autonomía.

Eso obliga a tratarlo como una nueva identidad dentro de la arquitectura. Cada agente que llega a producción debería estar inventariado, tener un propietario responsable y utilizar credenciales y permisos propios. También debería quedar claro qué puede hacer sin supervisión, qué acciones requieren aprobación humana y qué mecanismos permiten detener su funcionamiento.

Aplicar al agente los mismos permisos que tiene el usuario o el servicio que lo ejecuta puede concederle mucha más capacidad de la necesaria.

Una aplicación puede funcionar correctamente durante una prueba y resultar inservible cuando se enfrenta al volumen, la concurrencia o los tiempos de respuesta de un proceso real. Por eso "funciona" no debería ser el criterio con el que se autoriza un despliegue.

Antes de producción conviene establecer objetivos concretos: latencia máxima, disponibilidad, throughput, frescura del dato y capacidad de recuperación ante errores. Para determinados casos puede importar especialmente el tiempo hasta la primera respuesta; para otros, el coste y el número de operaciones que el sistema puede procesar simultáneamente.

Además, en una arquitectura agéntica la latencia acumulada puede crecer rápidamente porque una sola tarea encadena múltiples inferencias, consultas y llamadas a herramientas.

Proteger los datos no basta si el sistema que los utiliza tiene capacidad para ejecutar acciones. Los agentes amplían la superficie de riesgo mediante herramientas, credenciales, memorias, prompts y conexiones con aplicaciones corporativas.

La política más prudente consiste en comenzar con el principio de mínimo privilegio: negar por defecto y habilitar únicamente las fuentes y acciones que el caso necesita. También conviene separar las operaciones reversibles de las que pueden tener consecuencias económicas, legales o de seguridad y exigir intervención humana cuando corresponda.

Las pruebas previas al despliegue deberían incluir además intentos deliberados de manipular al agente, provocar accesos indebidos o utilizar información no autorizada. No se trata solo de comprobar si el modelo responde correctamente, sino si toda la arquitectura resiste un uso inesperado o adversarial.