Las empresas que crecen también necesitan rigor. Lo que no necesitan es burocracia.
La evaluación, las restricciones y el paso a una persona son la forma en que cualquier IA se gana la confianza. Los comités, las migraciones de plataforma y las hojas de ruta de dieciocho meses son opcionales. Los controles, no.
El problema de la burocracia
La IA empresarial tiene un problema de vocabulario. «Empresarial» suena a comités, plataformas, hojas de ruta de varios años y un equipo que lo coordina todo. Nada de eso es el estándar. Es la burocracia que ha crecido a su alrededor.
La burocracia sale cara. Las previsiones de los analistas apuntan a que más del 40 % de los proyectos de agentes de IA se habrán cancelado a finales de 2027, por el aumento de los costes, la falta de un valor de negocio claro y unos controles de riesgo insuficientes. No son fallos del modelo. Son fallos de gobernanza y de responsabilidad.
Una empresa en crecimiento no puede permitirse la burocracia. Tampoco puede permitirse saltarse los controles. La pregunta útil es qué partes del estándar empresarial generan confianza de verdad.
Qué es el estándar en realidad
El estándar es la promesa de que la IA se moverá dentro de unos límites y de que alguien responderá cuando no lo haga. No es una plataforma, un comité ni una hoja de ruta de dieciocho meses.
La promesa se sostiene en pruebas: las restricciones que acotan el sistema, la evaluación que lo pone a prueba, el paso a una persona que lo recoge y el registro de auditoría que lo explica. Sin esas pruebas, la promesa es marketing.
El estándar también es proporcional. Un primer proyecto puede llevar los mismos controles que un programa grande, con menos burocracia. Cambia el número de aprobaciones. El estándar, no.
Control uno: las restricciones
Las restricciones definen lo que el sistema puede decir y hacer. Son código y política, no una diapositiva.
Un conjunto útil de restricciones cubre cuatro límites. El del conocimiento: qué puede dar por cierto el sistema. El de la acción: qué herramientas puede invocar y qué registros puede modificar. El de la autoridad: qué puede prometer, aprobar o rechazar. El de la derivación: cuándo debe parar y pasar el caso a una persona.
Las restricciones deben escribirse antes de la primera conversación y probarse en producción. Una restricción que solo existe en un documento de políticas no es un control. Es un deseo.
Control dos: la evaluación
La evaluación es la forma en que el negocio sabe si el sistema está haciendo su trabajo. No es un número para la presentación: son pruebas sacadas del trabajo real.
Una evaluación práctica tiene cuatro partes. Un grupo de casos reales cuyo buen resultado ya se conoce. Un grupo de casos adversos: situaciones límite, peticiones ambiguas y entradas hostiles. Una muestra de producción que una persona revise cada semana. Un puñado de medidas que conecten el sistema con el resultado de negocio.
Repite la evaluación. Informa de la variación, no solo de la media. Un sistema que acierta una vez y falla a ratos no es fiable. Los marcos de gestión de riesgos ayudan, pero el hábito es más sencillo: prueba el trabajo, no la demostración.
Control tres: la derivación
La derivación es el control que hace segura la autonomía. Todo sistema necesita una forma limpia de devolver el trabajo a una persona con un resumen, un siguiente paso y el contexto necesario para que pueda seguir.
La derivación debe probarse como cualquier otro recorrido. ¿Quién la recibe? ¿Con qué rapidez? ¿Qué ve la persona? ¿Qué pasa si no está disponible? Una derivación que cae en una bandeja compartida sin contexto no es un control. Es una demora.
La mejor derivación se diseña con las personas que la van a recibir. Ellas saben qué necesitan para seguir el trabajo sin pedirle al cliente que repita todo.
Control cuatro: el registro de auditoría
El registro de auditoría es la forma en que el negocio responde a una pregunta más adelante. ¿Qué hizo el sistema? ¿Qué datos usó? ¿Qué regla aplicó? ¿Quién aprobó la excepción? ¿Qué cambió en el registro?
No hace falta que el registro sea un almacén gigante. Tiene que ser lo bastante completo para reconstruir una decisión. Una marca de tiempo, un identificador de conversación, las llamadas a herramientas, la versión del modelo, el resultado de las restricciones y el registro de la derivación suelen bastar.
El registro de auditoría también es una característica del producto. Permite que un cliente confíe en el sistema, que un regulador lo inspeccione y que un equipo lo mejore.
Control cinco: la responsabilidad
El control más importante es una persona. Un único responsable, con autoridad para parar el sistema y la obligación de explicarlo.
La responsabilidad no recae en un comité de dirección. Recae en una persona con nombre y apellidos que conoce el trabajo, ve las pruebas y toma la decisión. El responsable aprueba el criterio de cierre, las restricciones y la decisión de derivar el caso.
Sin un responsable, los otros cuatro controles se degradan. Las restricciones no son responsabilidad de nadie. La evaluación se hace una vez y se olvida. La derivación es una bandeja de entrada. El registro de auditoría es una carpeta que nadie lee.
Qué cambia con el tamaño
Un equipo pequeño puede mantener el mismo estándar sin las capas intermedias. La diferencia está en la coordinación que hace falta, no en la calidad de los controles.
Una empresa en crecimiento puede sacar adelante un primer proyecto acotado, con un responsable identificable, un conjunto escrito de restricciones, una evaluación real y una derivación limpia, en pocas semanas. Una empresa de mayor tamaño puede necesitar más aprobaciones, más documentación y más trabajo de integración. El estándar es el mismo. La burocracia es distinta.
El error es copiar la burocracia sin los controles. Un equipo de coordinación y una migración de plataforma no hacen fiable un sistema de IA. Una restricción, una evaluación y un responsable con nombre y apellidos, sí.
El primer proyecto
El primer proyecto es la prueba del estándar. Elige un trabajo con un resultado visible, acuerda cómo se va a medir y quédate hasta que el resultado sea real.
El primer proyecto debe ser lo bastante concreto para terminarlo y lo bastante importante para que cuente. Debe dejar al cliente un sistema en funcionamiento, un dosier de evaluación, un registro de auditoría y una forma de trabajar documentada. Son las pruebas que un programa mayor necesitaría de todos modos.
Si el primer proyecto no puede asumir los controles, no es un primer proyecto. Es una demostración con presupuesto.
Las preguntas antes de comprar
Quien compra puede poner a prueba el estándar antes de firmar. Pregunta quién responde del sistema después del lanzamiento. Pregunta cuáles son las restricciones. Pregunta cómo se evalúa el sistema y con qué frecuencia. Pregunta dónde está el registro de auditoría. Pregunta qué pasa cuando se marcha el proveedor. Pregunta cuál es el plan de salida.
Un proveedor que trata estas preguntas como obstáculos vende burocracia. Uno que las responde con detalle vende un sistema.
- ¿Quién responde del sistema después del lanzamiento?
- ¿Cuáles son las restricciones, en el código y en la política?
- ¿Cómo se evalúa el sistema y con qué frecuencia?
- ¿Dónde está el registro de auditoría?
- ¿Qué pasa cuando se marcha el proveedor?
- ¿Cuál es el plan de salida?
La capa normativa
La normativa eleva el mínimo, no sustituye el estándar. Las obligaciones de transparencia para los sistemas de IA se aplican desde el 2 de agosto de 2026. Las obligaciones para sistemas independientes de alto riesgo se aplican desde el 2 de diciembre de 2027, y desde el 2 de agosto de 2028 para la IA integrada en productos regulados. Las fechas importan, pero la dirección está clara: declara que hay IA, documenta el riesgo, mantén a una persona al frente y conserva las pruebas.
Una empresa en crecimiento no necesita un programa normativo para cumplir esa dirección. Necesita los cinco controles anteriores y la costumbre de conservar las pruebas.
Una norma de gestión de sistemas de IA da estructura a esa idea. Un marco de gestión de riesgos aporta un vocabulario de riesgo. Ninguno sustituye a nombrar un responsable y probar el sistema con casos reales.
La prueba
Una empresa en crecimiento no debería tener que elegir entre velocidad y rigor. Un primer proyecto bien acotado puede llevar los mismos controles que un programa grande, con un resultado que el negocio ve y una decisión que puede defender.
El rigor no es burocracia. Es un conjunto de controles que permite a un negocio moverse rápido sin jugarse lo que ha construido. Ese es el estándar que merece la pena conservar.
Sigue leyendo