Una demo de IA se monta en una tarde: un modelo de lenguaje, unos documentos y una pantalla para hacer preguntas. Ponerla a trabajar dentro de una empresa es otra cosa. Tiene que usar tus datos y solo los que tocan, responder con lo que es cierto, conectarse con tus sistemas, dejar rastro de lo que hace y no romperse cuando cambia el modelo.
Lo que separa una cosa de la otra es la arquitectura de IA: las piezas que rodean al modelo y cómo se conectan. Esta guía explica cuáles son y los patrones más habituales en empresas.
Las capas de un sistema con IA
| Capa | Qué hace | Ejemplos |
|---|---|---|
| Fuentes de datos | El conocimiento y los datos de la empresa | ERP, CRM, correo, documentos, bases de datos, web |
| Conocimiento (recuperación) | Encuentra la información relevante para cada pregunta o tarea | Índice de documentos troceados, embeddings, base de datos vectorial (por ejemplo, PostgreSQL con pgvector) |
| Modelo | Entiende, razona y redacta | Un modelo de lenguaje (LLM) de un proveedor u otro, o uno propio |
| Orquestación y herramientas | Decide los pasos y llama a las herramientas | Flujos de varios pasos, agentes con herramientas, llamadas a APIs, MCP |
| Código determinista | Lo que no debe hacer la IA | Cálculos, validaciones, reglas de negocio, escrituras en el ERP |
| Control | Evita respuestas inventadas o fuera de lugar | Filtros de entrada, respuestas solo con contenido aprobado, revisión de cada respuesta, derivación a una persona |
| Observación y evaluación | Saber si funciona y si empeora | Registro de conversaciones y acciones, baterías de preguntas de prueba, métricas |
| Seguridad y privacidad | Quién ve qué y dónde están los datos | Permisos, alojamiento en la UE, datos que no se usan para entrenar modelos |
El modelo es solo una de las capas. En la práctica, casi todo el trabajo y casi todos los problemas están en las demás.
Tres patrones habituales
1. Asistente con base de conocimiento (RAG). Un asistente responde preguntas de clientes o del equipo usando solo los documentos aprobados por la empresa. La pregunta se convierte en una búsqueda, se recuperan los fragmentos relevantes y el modelo redacta la respuesta con esos fragmentos y citando la fuente. Si no encuentra la respuesta, lo dice o deriva a una persona.
2. Automatización con extracción de datos. Un pedido o una factura llega en PDF por correo. La IA lee el documento y extrae los datos; el código los valida contra el ERP (cliente, artículos, precios); si todo cuadra, se registra solo, y si algo no cuadra, una persona lo revisa. La IA hace lo que el código no sabe hacer (entender un documento) y el código hace lo que la IA no debe hacer (decidir y escribir en el ERP).
3. Agente con herramientas. Un agente recibe un objetivo («prepara el presupuesto de esta solicitud») y decide qué herramientas usar: consultar el catálogo, calcular precios, redactar el documento. Es el patrón más potente y el que más control necesita: herramientas limitadas, permisos mínimos y validación humana antes de cualquier acción que no se pueda deshacer.
Cómo se controla que la IA no se invente cosas
Un sistema de empresa no puede depender de que el modelo «se porte bien». El control se diseña por capas:
- Antes: un filtro de entrada descarta las peticiones fuera de lugar.
- Durante: el modelo solo redacta con el contenido recuperado y aprobado, no con lo que «sabe».
- Después: un segundo control revisa cada respuesta antes de enviarla, y en caso de duda se deriva a una persona.
- Siempre: todo queda registrado, y una batería de preguntas de prueba se pasa cada vez que cambia algo (el modelo, los documentos o las instrucciones).
Decisiones de arquitectura que conviene tomar pronto
- No depender de un solo proveedor de modelos. Los modelos cambian cada pocos meses. Con una capa que aísle el proveedor, cambiar de modelo es una configuración, no un proyecto.
- Separar lo que hace la IA de lo que hace el código. Todo lo que se puede resolver con reglas, mejor con reglas: es más barato, más rápido y no se equivoca.
- Los datos, donde deben estar. Decidir dónde se alojan, qué proveedores los procesan y con qué condiciones antes de empezar, no después.
- Medir desde el principio. Sin registro ni pruebas no hay forma de saber si una mejora lo es.
- Empezar por un caso pequeño. Un proceso, con datos reales y un resultado medible, y crecer desde ahí.
Quién diseña la arquitectura
Diseñar estas piezas es el trabajo de un arquitecto de IA, y construirlas y conectarlas con los sistemas de la empresa, el de un integrador de IA. En Omitsis hacemos las dos cosas: diseñamos la solución para cada proceso, con código determinista o con IA, la integramos con tu ERP, tu CRM, tu correo y tus documentos, y la mantenemos.
Mira cómo lo aplicamos en nuestra página de integración de IA y en el servicio de implantación de IA en empresas, o cuéntanos tu caso.