IA empresarial: empezar por el proceso, no por el modelo

La conversación sobre IA empresarial suele empezar por el modelo: cuál razona mejor, cuál cuesta menos, cuál tiene más contexto o cuál puede llamar a más herramientas. En una empresa, esa decisión llega después.

Antes hay que definir qué resultado operativo buscamos, qué información puede utilizar el sistema, qué acciones puede ejecutar, qué nivel de error es tolerable y qué debe ocurrir cuando el caso sale de lo previsto.

1. Un modelo no es un sistema empresarial

Un modelo puede resumir, clasificar, extraer, redactar, comparar o proponer. Para producir valor de forma repetible necesita un entorno que convierta esa capacidad en una operación controlada.

Ese entorno incluye fuentes de verdad, instrucciones, herramientas, permisos, identidad de usuario, validaciones, límites, registro de actividad, tratamiento de excepciones y una acción posterior.

Una demo puede funcionar con un documento limpio y una pregunta bien formulada. La operación debe sobrevivir a información incompleta, formatos inesperados, datos contradictorios, usuarios distintos, integraciones caídas y situaciones que nadie incluyó en la demo.

La IA aporta capacidad. El sistema convierte esa capacidad en un resultado controlado.

2. Empieza por una métrica del proceso

“Usar IA” no es un objetivo empresarial. “Reducir el tiempo de clasificación de expedientes sin aumentar errores”, “preparar propuestas más rápido manteniendo revisión humana” o “detectar solicitudes que necesitan atención antes de superar un SLA” sí son objetivos operativos.

Define una métrica primaria y varias métricas de guardarraíl. Si optimizas velocidad, vigila calidad. Si optimizas autonomía, vigila excepciones. Si optimizas coste, vigila experiencia de cliente.

3. Diseña ocho capas antes de producción

1. Objetivo

Qué resultado debe mejorar y cómo sabremos si mejoró.

2. Disparador

Qué inicia el sistema: una solicitud, un documento, un cambio de estado, una conversación o una programación.

3. Entrada

Qué datos mínimos necesita y cómo se valida que están presentes.

4. Contexto

Qué fuentes puede consultar, cuál prevalece ante conflicto y qué información no debe inferir.

5. Razonamiento

Qué tarea cognitiva realiza: clasificar, extraer, comparar, generar, priorizar o decidir dentro de límites.

6. Acción

Qué sistemas puede consultar o modificar. Leer un CRM y enviar un pago son niveles de riesgo muy diferentes.

7. Control

Qué necesita aprobación, qué umbrales existen y qué condiciones obligan a detenerse.

8. Observabilidad

Qué se registra para entender calidad, coste, errores, decisiones y comportamiento en el tiempo.

4. La fuente de verdad importa más que el prompt

Si una política, precio, estado de cliente o documento contractual existe en varias versiones, el modelo no puede resolver una contradicción organizativa por arte de magia.

Define qué repositorio manda, quién lo mantiene y cómo se identifica la versión vigente. Si el sistema recupera contexto desde varias fuentes, establece prioridades y filtros de autorización.

La IA puede encontrar información con gran flexibilidad, pero esa flexibilidad no sustituye el gobierno del dato.

5. Separa conocimiento de acción

Un sistema que responde una pregunta y un sistema que modifica el mundo no deben tratarse igual.

Conviene dividir la arquitectura en dos pasos:

1. Determinar qué debería ocurrir.
2. Autorizar y ejecutar la acción.

Esta separación permite aplicar validaciones deterministas, permisos y aprobaciones antes de tocar datos, enviar comunicaciones o ejecutar transacciones.

6. No preguntes “¿puede hacerlo?”, pregunta “¿debe hacerlo solo?”

El nivel de autonomía debe depender del coste del error, la reversibilidad y la facilidad para detectar que algo salió mal.

La supervisión humana no debe ser un botón decorativo. La persona que supervisa necesita contexto suficiente, autoridad para intervenir y una carga de revisión compatible con el volumen.

7. Evita la “aprobación humana” que no puede funcionar

Si una persona recibe cientos de decisiones generadas por IA y solo dispone de segundos para revisarlas, la aprobación puede convertirse en una formalidad.

Diseña la revisión para que muestre la información necesaria para decidir: fuente, evidencia, nivel de confianza cuando exista, cambios propuestos y consecuencias de aprobar.

También define cuándo una revisión es obligatoria y cuándo el sistema puede actuar directamente.

8. Gestiona riesgo según impacto y contexto

El marco AI RMF de NIST propone gestionar el riesgo de IA de forma continua y contextual, considerando impactos, roles, medición y gobierno a lo largo del ciclo de vida. NIST también recomienda definir procesos de supervisión humana y mapear riesgos y beneficios de los componentes del sistema.

En la Unión Europea, el AI Act establece requisitos específicos para sistemas clasificados como de alto riesgo, incluyendo gestión de riesgos, gobierno de datos, documentación, registros, transparencia, supervisión humana, precisión, robustez y ciberseguridad. No todos los sistemas de IA son de alto riesgo; la clasificación depende del uso y del marco definido por el Reglamento.

Para un proyecto empresarial, una matriz simple puede evaluar cada acción por:

• Magnitud del daño posible.
• Probabilidad de error.
• Detectabilidad.
• Reversibilidad.
• Sensibilidad de los datos.
• Impacto sobre personas.
• Obligaciones legales o contractuales.

9. Define permisos con mínimo privilegio

El sistema debería disponer únicamente de los permisos necesarios para su función. Si necesita leer pedidos, no necesita necesariamente editar clientes. Si prepara borradores, no necesita necesariamente capacidad de envío.

Cuando una herramienta permite acciones sensibles, introduce límites: importes máximos, tipos de registro, entornos permitidos, dominios autorizados o acciones que siempre requieren aprobación.

10. No uses el modelo para reglas que pueden ser deterministas

Validar formato de email, comprobar un importe máximo, verificar que existe un consentimiento o impedir una acción fuera de horario son reglas que suelen ser más fiables como lógica determinista.

Utiliza IA donde aporta valor: lenguaje ambiguo, clasificación flexible, extracción de texto, síntesis o apoyo a decisiones. Combínala con software tradicional para límites y controles.

11. Evalúa comportamiento, no impresiones

Antes de producción crea un conjunto de casos representativos del trabajo real. Incluye casos normales, ambiguos, incompletos, adversos y de borde.

Para cada caso define qué resultado es aceptable. La evaluación puede medir:

• Exactitud de clasificación.
• Extracción correcta de campos.
• Cumplimiento de reglas.
• Uso de fuentes autorizadas.
• Escalado correcto.
• Calidad de la acción propuesta.
• Latencia.
• Coste.

No basta con preguntar a alguien si la respuesta “parece buena”. Un texto puede sonar excelente y estar basado en el dato equivocado.

12. Prueba fallos de integración

El sistema debe saber qué hacer cuando una API no responde, una credencial caduca, una base de datos devuelve datos parciales o una herramienta confirma una acción con retraso.

Diseña idempotencia cuando exista riesgo de duplicar acciones, reintentos controlados, timeouts y estados intermedios que permitan saber qué se ejecutó realmente.

13. Registra lo suficiente para investigar

La observabilidad debería permitir responder: qué entrada recibió el sistema, qué contexto utilizó, qué decisión produjo, qué herramienta llamó, qué resultado recibió y qué ocurrió después.

No todo debe almacenarse indefinidamente. El diseño de logs debe respetar privacidad, seguridad y minimización de datos.

14. Controla coste y latencia como parte del producto

Un flujo técnicamente correcto puede no ser viable si tarda demasiado o cuesta más que el valor que produce.

Mide coste por caso y distribuciones de latencia. Observa especialmente casos complejos, porque suelen consumir más contexto, más llamadas y más herramientas.

Después decide dónde conviene usar un modelo más potente, uno más pequeño, lógica determinista o caché.

15. Diseña la operación después del lanzamiento

La IA no elimina mantenimiento. Introduce una capa nueva que también cambia con el tiempo.

16. Versiona prompts, herramientas y evaluaciones

Si cambias instrucciones, modelo, herramientas o fuentes, cambia el comportamiento del sistema. Trátalo como una versión nueva.

Ejecuta el conjunto de evaluación antes de producción y compara resultados. Esto reduce regresiones invisibles.

17. Diferencia fallo del modelo, fallo del proceso y fallo del dato

Cuando una salida es incorrecta, clasifica la causa. Si el modelo no entendió una instrucción, la solución es distinta a si la fuente contenía un precio obsoleto o si nadie había definido qué hacer ante ese caso.

Esta taxonomía evita intentar arreglar todos los problemas modificando el prompt.

18. Cómo elegir el primer caso de uso

Busca una situación repetida, medible, con datos accesibles y coste de error controlable. Debe existir una línea base y una persona que pueda validar el resultado.

Un buen primer caso suele tener:

• Volumen suficiente.
• Resultado observable.
• Datos disponibles.
• Acción reversible o supervisable.
• Excepciones manejables.
• Beneficio que pueda medirse.

Además, debería generar capacidades reutilizables: autenticación, acceso a datos, evaluación, observabilidad, tratamiento de excepciones y controles.

19. Ejemplo de arquitectura: clasificación de solicitudes

Ejemplo hipotético: una empresa recibe solicitudes por email y formulario. El objetivo es clasificarlas y asignarlas al equipo correcto.

1. El sistema recibe la solicitud.
2. Valida que exista información mínima.
3. Consulta una fuente autorizada para identificar cliente o contrato.
4. La IA clasifica intención y prioridad.
5. Reglas deterministas validan que la prioridad no supere límites sin evidencia.
6. Casos de baja confianza se envían a revisión.
7. Casos normales se crean en el sistema de tickets.
8. Se registra el resultado y la clasificación final.
9. Las correcciones humanas alimentan la evaluación futura.

La IA es solo el paso 4. El valor empresarial depende de todo el sistema.

20. Señales de que todavía no estás listo

• No existe fuente de verdad.
• No se puede explicar qué resultado significa éxito.
• Nadie es propietario del proceso.
• La organización no sabe qué acciones requieren aprobación.
• No existe forma de detectar errores.
• El caso depende de datos a los que el sistema no puede acceder de forma fiable.
• El único argumento es “la competencia está usando IA”.

Conclusión

La ventaja de un sistema empresarial con IA no viene de escoger el modelo más llamativo. Viene de integrar capacidad probabilística dentro de un proceso claro, con información autorizada, límites, permisos, supervisión, evaluación y operación.

Cuando esos elementos están diseñados, cambiar de modelo puede ser una decisión técnica. Cuando no lo están, ningún modelo arregla la falta de proceso.

Fuentes y referencias oficiales

• NIST — AI Risk Management Framework.
• NIST AIRC — AI RMF Core, incluyendo prácticas sobre supervisión humana, mapeo de riesgos y controles.
• NIST — Generative AI Profile.
• Comisión Europea — estructura del AI Act, requisitos para sistemas de alto riesgo y obligaciones relacionadas.
• Comisión Europea — guía sobre obligaciones de proveedores y deployers.

Este artículo explica criterios de diseño y operación; no sustituye asesoramiento jurídico para determinar obligaciones concretas bajo el AI Act u otra normativa.

Si quieres ver cómo estructuramos el análisis antes de implantar un sistema, consulta cómo trabajamos.