Artículo escrito por Ivan Hernanz, Senior Cloud Architect en ACKstorm, y experto en IA.
La inteligencia artificial ya no es solo una herramienta que responde preguntas o ayuda a escribir textos. Cada vez más, se conecta a datos, aplicaciones, procesos internos y sistemas reales de una empresa. Cuando una IA empieza a tomar decisiones, ejecutar acciones o influir en procesos de negocio, la gobernanza deja de ser algo opcional y pasa a formar parte del diseño del sistema desde el principio.
Por eso, LLMOps no debería entenderse solo como poner un modelo de IA en producción. El verdadero desafío aparece cuando varios equipos empiezan a usar modelos, prompts, proveedores, datos sensibles y herramientas distintas.
En ese momento hacen falta responsables claros, trazabilidad, control de costes, gestión de riesgos y criterios para decidir qué arquitectura usar en cada caso.
La pregunta importante ya no es solo si la IA funciona, sino si puede escalar de forma segura, controlada, medible y alineada con el negocio.
Cuando la IA pasa de sugerir a ejecutar...
Estamos conectando GenAI a tools, MCPs, APIs, datos, repositorios y workflows… pero muchas veces seguimos gobernándola como si fuera un chatbot.
Durante mucho tiempo hemos hablado de GenAI como si el reto principal fuera mejorar la interacción con el modelo: mejores prompts, más contexto, copilotos más útiles, más conectores y más automatización alrededor.
Pero esa lectura empieza a quedarse corta. El cambio importante no está sólo en conectar más capacidades al modelo, sino en lo que ocurre cuando esas capacidades empiezan a operar sobre sistemas reales. En ese punto, GenAI deja de comportarse como una interfaz inteligente y empieza a parecerse mucho más a una capa operacional dentro de la arquitectura.
Y eso cambia el tipo de riesgo. Ya no hablamos sólo de una respuesta incorrecta o incompleta. Hablamos de una acción ejecutada con contexto desactualizado, permisos mal definidos, una tool incorrecta, una política no aplicada, un coste no previsto o una cadena de pequeños errores que nadie detecta a tiempo.
El debate real es si esa capacidad de ejecución opera dentro de límites aceptables para la organización: con ownership claro, políticas explícitas, permisos bien definidos, trazabilidad, evaluación continua, control de coste, gestión de riesgo y aprobación humana cuando haga falta.
Ahí la gobernanza no puede aparecer como una checklist al final. Tiene que formar parte del diseño desde el principio.
La importancia del Harness Engineering
No veo el Harness Engineering como otro término de moda, sino como una forma práctica de aterrizar esa gobernanza en sistemas agentic. Un agente en producción no debería ser simplemente un LLM con acceso a tools; debería operar dentro de un contrato explícito de ejecución.
Ese contrato debería definir qué puede hacer, sobre qué recursos, con qué permisos, usando qué memoria, bajo qué límites de coste, con qué validaciones, con qué trazabilidad y cuándo debe parar o pedir aprobación humana.
En otras palabras, el harness engineering convierte reglas de gobierno en condiciones reales de ejecución. Su objetivo no es frenar la autonomía, sino hacerla operable: permitir que un sistema ejecute dentro de límites conocidos, observables y auditables.
Ese es el verdadero reto: delegar capacidad de acción en sistemas autónomos sin perder control, responsabilidad ni trazabilidad.
Mi conclusión: Si la IA pasa de sugerir a ejecutar, la gobernanza deja de ser un complemento. Se convierte en parte del diseño del sistema.
Y en ese diseño, el modelo es sólo una pieza. El resto es runtime, memoria, herramientas, permisos, observabilidad, evaluación continua, control de coste, trazabilidad y capacidad de intervención humana.
3 errores más comunes al intentar escalar IA sin gobernanza clara
Hace un año pensábamos que hacer LLMOps era poner un modelo en producción. Elegir modelo, montar endpoint, añadir RAG, probar unos prompts, hacer una demo bonita. Y sí, la demo funcionaba.
El problema apareció cuando aquello empezó a crecer. Ahí entendimos algo incómodo: LLMOps no va de desplegar un LLM. Va de gobernar/operar una capacidad de lenguaje dentro de una organización. Y, en ese camino, hay tres errores que veo repetirse mucho:
1. Error: no tener un owner claro de gobernanza LLM
Cuando nadie es accountable, todo se diluye. IT mira la plataforma, negocio mira el caso de uso, seguridad mira el riesgo, finanzas mira la factura. Pero nadie mira el sistema completo.
- ¿Quién aprueba un cambio de modelo?
- ¿Quién valida un prompt crítico?
- ¿Quién decide si una fuente de conocimiento puede usarse?
- ¿Quién responde si una salida genera un problema?
Sin ownership, LLMOps se convierte en una suma de experimentos.
2. Error: mirar la factura y no los tokens
En IA, gobernar costes no es mirar cuánto cobra el proveedor a final de mes. Eso llega tarde. La unidad real de control es mucho más pequeña: coste por request, por usuario, por feature, por agente,por modelo, por proveedor. Hasta que no sabes qué flujo está quemando tokens, estás optimizando a ciegas.
Puedes cambiar de modelo, puedes recortar contexto, puedes cachear, puedes enrutar a otro proveedor, puedes limitar usos por equipo.
Pero sólo si tienes trazabilidad real. Los tokens son una unidad técnica, pero también son una unidad financiera.
3. Convertir la arquitectura en religión
Primero suele llegar el “todo SaaS”. Luego aparece la preocupación por coste, soberanía o datos sensibles, y alguien propone el extremo contrario: “todo self-hosted”, y normalmente ninguno de los dos extremos aguanta bien la realidad. La arquitectura de inferencia debería ser una política, no una religión.
- APIs/MaaS para ir rápido y experimentar.
- Proveedores europeos cuando hay PII o requisitos regulatorios.
- GPUaaS u on-prem sólo cuando el volumen y la estabilidad justifican la operación.
- La pregunta no es: “¿SaaS o self-hosted?”
- La pregunta es: “¿Qué tipo de carga, dato, riesgo y coste justifica cada opción?”
Cuando empezamos a verlo así, la conversación cambió. Ya no hablábamos sólo de modelos. Hablábamos de ownership, trazabilidad, coste, riesgo, calidad y decisión arquitectónica. Y ahí es donde LLMOps empieza a parecerse menos a una demo brillante… y más a una plataforma que el negocio puede tomarse en serio.
Mi conclusión: El verdadero salto no es hacer que GenAI funcione. Es hacer que escale con gobierno: ownership, trazabilidad, coste, riesgo, calidad y criterios claros de arquitectura.
Muchas organizaciones están justo ahí: ya no juegan con GenAI, pero todavía no la gobiernan como plataforma.
El siguiente paso: construir un Control Plane de Gobernanza IA
Una plataforma GenAI no madura cuando añade más modelos, más tools, más MCPs o más automatizaciones. Madura cuando puede gobernar todo eso sin perder control.
Al principio, GenAI suele entrar por casos de uso concretos: un asistente interno, un RAG, un copiloto, un agente de desarrollo o una automatización conectada a herramientas corporativas.
Cada iniciativa parece razonable por separado. Permite aprender rápido, demostrar valor y evitar discusiones eternas antes de tener evidencia.
El problema aparece cuando esos casos dejan de ser experimentos aislados y empiezan a comportarse como una capacidad transversal de la organización. Ahí ya no basta con que cada equipo gobierne “lo suyo”.
Sin una vista común de qué se usa, quién lo mantiene, bajo qué reglas opera y qué impacto puede tener, la plataforma crece, pero la gobernanza no crece con ella.
Entonces el problema ya no es sólo técnico. Es operativo. Aparecen decisiones distribuidas sin criterio común, costes que se entienden tarde, cambios de comportamiento difíciles de evaluar y flujos que nadie puede reconstruir completamente cuando hay una incidencia.
Por eso creo que el siguiente paso en LLMOps no es simplemente automatizar más. Es construir un verdadero control plane de gobernanza GenAI.
No hablo de comprar “una herramienta de gobierno” y pensar que el problema queda resuelto. Hablo de diseñar una capa explícita dentro de la plataforma donde las capacidades GenAI se registran, versionan, autorizan, observan y auditan.
Ese control plane debería ordenar modelos, prompts, agentes, tools, MCPs, memoria, fuentes de conocimiento, evaluaciones, costes, riesgos y owners.
No para crear burocracia, sino para que cada capacidad tenga contexto claro: responsable, casos permitidos, datos que puede manejar, herramientas que puede invocar, límites de coste y nivel de intervención humana.
Una plataforma GenAI madura no puede depender de que cada equipo recuerde aplicar buenas prácticas manualmente. Necesita mecanismos comunes: un catálogo vivo de capacidades, un runtime o gateway para aplicar políticas y observar consumo, evaluación continua para medir cambios de comportamiento y trazabilidad para reconstruir qué ocurrió cuando algo falla.
También necesita una gestión del riesgo proporcional. No se gobierna igual un asistente interno de baja criticidad que un agente capaz de modificar datos, tomar decisiones operativas o interactuar con clientes.
La gobernanza madura no consiste en frenar GenAI. Consiste en hacer explícitas las condiciones bajo las cuales GenAI puede escalar sin convertirse en una fuente de riesgo sistémico.
Conclusiones: cómo escalar IA eficazmente sin desperdiciar costes ni recursos
La evolución de la Inteligencia Artificial Generativa desde una herramienta de sugerencia a una capa operacional capaz de ejecutar acciones sobre sistemas reales reconfigura el desafío principal: la gobernanza no es un complemento, sino parte integral del diseño.
El verdadero reto de LLMOps no es solo desplegar un modelo (o una «demo brillante»), sino asegurar que la GenAI escale de forma segura, controlada y alineada con el negocio. Esto requiere superar errores comunes como la falta de ownership claro, la incapacidad de trazar costes a nivel de token y las arquitecturas rígidas.
La madurez de una plataforma GenAI se alcanza al construir un Control Plane explícito de gobernanza, que sustituya la gestión distribuida por equipos por una capa centralizada. Este Control Plane registra, autoriza y audita cada capacidad, permitiendo que los agentes operen con una autonomía funcional dentro de un «contrato de ejecución» predefinido (Harness Engineering).
Al establecer mecanismos comunes de observabilidad, políticas y gestión de riesgos proporcional, la organización transforma una colección de iniciativas GenAI en una capacidad gobernada, previniendo que el escalado se convierta en una fuente de riesgo sistémico.
