Un modelo solo no es una operación

La demo salió perfecta. Pegaste una factura desordenada en ChatGPT o en Claude, leyó los campos, contestó las preguntas y alguien en la sala dijo lo que todos pensaban: esto lo cambia todo. Después el proyecto avanzó hacia producción y se fue desarmando sin ruido. El mismo modelo que deslumbró con diez ejemplos limpios empezó a saltarse campos con más volumen, se atoró con escaneos malos y el martes dio otra respuesta que el lunes a la misma pregunta.

Un modelo público está hecho para sonar plausible. Tu operación tiene que ser correcta, segura y confiable cada vez. Son metas distintas, y en la distancia entre ellas se caen los proyectos. El modelo nunca fue la parte difícil. Lo difícil es todo lo que lo rodea.

Leer una factura no es procesarla

Toma cuentas por pagar en una empresa que recibe miles de facturas de cientos de proveedores. En producción aparece lo que la demo no mostró. Aunque la factura electrónica tenga formato estándar, la orden de compra viene en la referencia, en la glosa o en ninguna parte. Las notas de crédito se parecen a facturas. El flete y los impuestos adicionales aparecen donde a cada proveedor se le ocurre.

Que la extracción sea confiable exige validarla contra muchas facturas históricas, y aun así es apenas el comienzo. Cada factura tiene que pasar la validación del negocio, cuadrar contra la orden de compra y la recepción, seguir la política de aprobación, contabilizarse bien en el ERP, recuperarse si la transacción falla y dejar registro. Ningún área de finanzas genera valor leyendo documentos. El valor está en cerrar la transacción, y si esos pasos no están construidos dentro del flujo, el modelo solo le pasó datos correctos a una persona que igual termina el trabajo a mano. El cuello de botella se cambió de lugar.

Por qué la demo funciona y el despliegue se cae

La demo prueba si el modelo puede hacer la tarea una vez, con insumos limpios y una persona mirando. Producción prueba si puede terminar el trabajo completo, con datos sucios, a volumen real, todos los días y sin supervisión.

Un modelo público es extraordinario para producir una respuesta fluida y probablemente correcta, y eso es lo que premia una demo. "Casi siempre correcto" sirve para un borrador de marketing. La columna operativa de una empresa no tiene ese margen. Cuando se contabilizan facturas o se aplican pagos, casi siempre correcto quiere decir equivocado lo bastante seguido como para doler, y los errores no avisan. Aparecen semanas después, en el cierre de mes o en la auditoría.

Casi nadie tiene cómo pillarlos a tiempo: según McKinsey, en 2025 apenas cerca del 1 % de las empresas se consideraba madura en IA. La demo esconde todo esto porque está hecha para esconderlo.

Un modelo más inteligente no lo resuelve

Un modelo de frontera puede razonar brillante un caso difícil y aun así reprobar las pruebas de una operación. No garantiza la misma salida dos veces, y una transacción lo exige. Por sí solo no se mantiene dentro de tu política, porque no tiene ninguna noción obligatoria de cuál es. Y no puede demostrar qué hizo ni por qué, que es lo primero que pregunta un auditor. Hacerlo más inteligente mejora la respuesta promedio, pero no hace nada por la consistencia, la seguridad ni la responsabilidad.

La diferencia, punto por punto:

• Precisión: el modelo da respuestas plausibles; producción necesita precisión de transacción, verificada contra tus datos.

• Consistencia: el modelo varía de una corrida a otra; producción necesita el mismo resultado correcto cada vez.

• Tus datos: con el modelo público salen de tu empresa; producción necesita una instancia aislada y datos que no entrenan ningún modelo.

• Sistemas: el modelo es una caja donde pegas texto; producción lee y escribe en vivo en tu ERP, tu CRM y tus portales.

• Controles: el modelo no trae ninguno; producción necesita aprobaciones, separación de funciones, registro y reversa.

El control parece burocracia hasta que la IA actúa

Un agente que solo lee datos parece de bajo riesgo, y los controles parecen opcionales. Cuando ese agente escribe en tu ERP, mueve caja o tramita en un portal, la trazabilidad, las aprobaciones y la reversa pasan a ser la diferencia entre un activo y un pasivo.

Cuando un agente de IA falla en una empresa, casi siempre es por las mismas razones: autoridad sin control, datos de decisión defectuosos, resultados impredecibles y falta de registro de auditoría. Las cuatro son fallas de control. El equipo eligió un modelo capaz y se saltó la capa que lo vuelve seguro de operar.

Una política de IA declara una intención; el control se aplica en el momento de la acción. Los frenos no se le ponen a un auto que ya va cuesta abajo.

Lo que cierra la distancia

La infraestructura, el modelo y los frameworks para armar agentes los arrienda cualquiera con una tarjeta de crédito, y tu competencia ya los tiene. La operación está en lo que va encima. Nosotros la ordenamos en las seis decisiones que una empresa toma con cualquier persona que entra.

Qué puede ver: el proceso real del cargo, con sus reglas de decisión, sus excepciones y sus umbrales de aprobación, escrito en un manual que es del cliente.

Qué puede hacer: una lista cerrada de herramientas con nombre, con escrituras validadas en tu ERP y reversa cuando algo sale mal.

Qué tiene prohibido: lo que no firma, lo que no promete y lo que tiene que pasar por una persona, escrito también en código para que no dependa de que el modelo lo entienda.

Qué recuerda: una carpeta por caso que el cliente abre cuando quiere, y no la memoria del modelo, que se borra al cerrar la conversación.

Quién revisa: un jefe con nombre que aprueba lo que pesa, después de un examen con casos reales que ya sabemos cómo terminan.

Qué queda anotado: cada acción con su porqué, su respaldo y su costo, y el resultado del negocio además de la tarea. La medida es que la factura se pagó y nadie reclamó.

Sobre eso va la cuenta. En producción, miles de facturas al año con varias consultas cada una cambian la economía por completo. Por eso cada paso va a la tecnología que le corresponde: un modelo de frontera para el juicio, uno pequeño donde el dato no puede salir, visión para los documentos y reglas fijas para lo que nunca puede variar. Lo que se mide es el costo por transacción bien terminada.

Nada de esto viene con el modelo, y todo junto es la operación: la inteligencia de un modelo de frontera con la confiabilidad que exigen tus transacciones. Eso separa a un agente que hace tareas de un colaborador digital que se hace cargo de un puesto. Y el modelo queda como una pieza que se cambia cuando aparece uno mejor.

Los modelos de frontera son notables y van al centro, pero no son el sistema. El modelo es el motor. La operación es el motor más los frenos, la dirección, el tablero y un conductor que responde por dónde termina el auto.

La pregunta que decide tu proyecto no es cuál modelo es mejor. Esa es la parte fácil, y cambia cada pocos meses. La pregunta es qué hay alrededor. Si hoy estás evaluando un proyecto de IA, deja de ponerle nota al modelo y pónsela a todo lo que lo rodea.

Fuentes

• McKinsey & Company, 2025: cerca del 1 % de las empresas se considera madura en IA.