Arquitectura empresarial de IA: cómo encaja con lo que ya tienes

Las cinco capas, y qué decide cada una

El valor de separarlas es que cada una se puede cambiar sin rehacer las otras, que es lo que hace que un sistema envejezca bien.

La mayoría de proyectos empieza por la cuarta y la quinta, que son las que se ven. Y descubre en el mes dos que la segunda no existe.

Hay una consecuencia práctica de separar las capas que se nota al segundo caso de uso: lo que se construyó para el primero se reutiliza.

Si el acceso al CRM se construyó dentro del primer agente, el segundo lo construye otra vez. Si se construyó como capa, el segundo lo usa y arranca en días.

Es la diferencia entre que el segundo caso cueste lo mismo que el primero o una fracción, y esa diferencia decide si habrá un tercero.

El principio que ahorra más problemas: no tocar el origen

La tentación de modificar el ERP o el CRM para que «encaje mejor» aparece siempre y casi siempre es un error.

Un sistema de origen modificado para un proyecto de IA se vuelve más difícil de actualizar, y cuando el proveedor saque su versión nueva la empresa tiene que elegir entre actualizar y conservar lo suyo.

La alternativa es construir la capa de acceso encima: leer lo que hay, transformar fuera y devolver sólo por las vías oficiales.

La capa de acceso, donde está el trabajo real

Es la menos glamorosa y la que decide si el proyecto avanza o se atasca.

• Sistemas con API razonable. Lo más fácil. Se conecta y se avanza.
• Sistemas con API pobre o con límites duros. Hay que diseñar alrededor: caché, extracciones periódicas, colas.
• Sistemas sin API. Hay que construir una encima o descartarlos del alcance. Conectar por vías no oficiales dura hasta la primera actualización.
• Hojas de cálculo que son la fuente real. Más común de lo que nadie admite en la primera reunión.

El cuarto caso merece una decisión explícita: o se convierte en un sistema de verdad, o se acepta como fuente y se le pone un proceso alrededor. Ignorarlo y descubrirlo a mitad del proyecto es lo que más plazos rompe.

Sobre el segundo caso, los sistemas con límites duros: la salida habitual es una copia intermedia que se refresca cada cierto tiempo.

Eso resuelve el límite y abre una pregunta nueva que hay que responder de forma explícita: cuánto desfase se acepta. Para un catálogo, horas. Para el saldo de un cliente, ninguno.

Cuando esa pregunta no se responde, el sistema termina respondiendo con datos de ayer sin que nadie lo haya decidido.

La capa de contexto, la que casi nadie planifica

Entre los datos crudos y la IA hay una capa de preparación que rara vez está en el diagrama inicial y siempre acaba existiendo.

• Definiciones compartidas. Qué es un cliente activo, qué cuenta como venta cerrada. Si cada área lo define distinto, la IA hereda la ambigüedad.
• Índices de documentos, si hay búsqueda sobre texto.
• Memoria de interacciones, si el sistema tiene que recordar entre sesiones.
• Histórico ordenado, para poder comparar contra lo que pasó antes.

El primero es el que más discusión genera y el que más valor tiene fuera de la IA. Una empresa que acuerda sus definiciones gana consistencia en todos sus reportes, con modelo o sin él.

Dónde vive cada cosa

Tres decisiones de ubicación, cada una con su compensación, y ninguna es obviamente correcta.

La decisión no tiene que ser la misma para todas las capas. Es habitual y razonable que el contexto viva dentro y el modelo fuera, que es el reparto que más empresas medianas terminan eligiendo. El contraste completo está en IA en la nube contra on premise.

En qué orden se construye

De abajo hacia arriba, aunque la presión sea siempre por enseñar la capa cinco cuanto antes.

El paso dos es donde se atascan la mayoría de proyectos, y donde conviene poner el esfuerzo de estimación. Si la capa de acceso no está resuelta, todo lo de arriba es una demo.

Señales de que la arquitectura está mal planteada

Cinco síntomas que aparecen entre el mes tres y el seis.

• Cada caso de uso nuevo obliga a rehacer la conexión con el mismo sistema.
• Cambiar de modelo implica tocar la lógica de negocio.
• Nadie sabe de dónde salió un número que el sistema mostró.
• Hay tres definiciones distintas de la misma métrica dentro del mismo sistema.
• El proyecto depende de que una persona esté disponible.

Los cinco tienen la misma raíz: capas que se mezclaron. Y todos se corrigen mucho más barato en el mes tres que en el dieciocho.

El diagrama mínimo que hay que tener

No hace falta un documento de arquitectura de cincuenta páginas. Hace falta una hoja con cuatro cosas.

• Qué sistemas de origen entran y por dónde se accede a cada uno.
• Qué se prepara en el medio y quién lo mantiene.
• Qué decide cada pieza y dónde está el límite.
• Dónde lo usa la gente.

Con esa hoja, cualquier persona nueva entiende el sistema en veinte minutos. Sin ella, el sistema es una dependencia de quien lo construyó. El detalle de qué documentar está en cómo se documenta una arquitectura de IA.

Qué hacer cuando ya hay tres sistemas construidos sin arquitectura

Es la situación más común en empresas que empezaron por casos sueltos, y no hace falta rehacer nada para ordenarla.

El primer paso es dibujar lo que hay: qué sistema toca qué, con qué credencial y qué se duplicó. El dibujo suele revelar que dos de los tres leen lo mismo de formas distintas.

A partir de ahí se extrae lo compartido a una capa común, empezando por el acceso que más se repite. No es un proyecto de meses: es una refactorización acotada que se paga en el siguiente caso de uso.