Cómo hacer que la IA siga el método de tu empresa

Por qué la IA entrega un trabajo bueno que no sirve#

El reclamo más común de quien empezó a usar IA en el trabajo no es que se equivoque. Es que acierta algo que no es lo tuyo: el texto está bien escrito, la estructura es razonable — y no es así como lo hace tu empresa.

El motivo es simple. Un modelo de lenguaje devuelve algo cercano al promedio de lo que se publicó sobre el tema, y tu método no está publicado: vive en la cabeza de dos o tres personas, en un documento desactualizado y en un montón de decisiones que nadie escribió. Pedir "hazlo a nuestra manera" a algo que nunca vio tu manera devuelve la manera de todo el mundo.

Restringir un modelo a una metodología es resolver eso — y la respuesta no es un mejor prompt. Son cuatro capas, en orden de costo:

1. El método escrito fuera del prompt, y leído al momento de usarlo.
2. El cálculo en código, fuera de las manos del modelo.
3. La lista de lo prohibido, con el vocabulario que entra en su lugar.
4. Un freno que detiene la acción, para lo que no puede depender de buena voluntad.

Si el método no está escrito, no hay nada que restringir#

Restringir es comparar contra una referencia. Sin referencia escrita no hay restricción: hay un pedido, y el modelo cumple el pedido llenando el vacío con lo que parece correcto.

Es el escalón que casi todos se saltan, porque no tiene nada de tecnológico. En nuestra operación tomó la forma de 26 metodologías escritas — alcance, estimación, planificación de interfaz, revisión de código, mapa de notificaciones, documento legal, y así — ejecutadas por 28 comandos que no llevan el método adentro: leen la metodología correspondiente en el momento en que corren (cifras de agosto de 2026).

Vale la confesión que cierra el argumento: diseñamos un producto interno y paramos antes de construirlo, porque la metodología que debía vigilar todavía no estaba validada en campo. Sin ella, el producto sería un chat genérico escuchando una reunión: lindo en la demo, inútil a la hora de exigir rigor. El software era la parte fácil.

La prueba, antes de comprar cualquier capa de IA: ¿alguien nuevo en la empresa podría ejecutar este proceso leyendo solo lo que está escrito? Si la respuesta es no, el modelo tampoco va a poder. Solo va a equivocarse más rápido y con más confianza.

La regla vive fuera del prompt, y se lee al momento de usarla#

Hay dos formas de darle un método a un agente de IA. La primera es escribir el método dentro del prompt. La segunda es escribir el método en un documento e instruir al agente a leer ese documento al ejecutar la tarea.

Parece un detalle de implementación, y es una de las decisiones más consecuentes de la arquitectura. La tomamos formalmente, y la razón es la duplicación: cuando el método vive en dos lugares, uno de los dos envejece. La regla cambia en el documento, el prompt sigue aplicando la versión anterior, y nada avisa — la salida sigue pareciendo correcta, porque es correcta respecto de una regla que ya no vale.

En la práctica el agente es solo un orquestador: pregunta, lee los insumos, valida y genera. El método vive en el documento: cambió el estándar, cambia en un solo lugar.

El segundo efecto importa incluso más: el método sigue siendo legible para quien no toca prompts. Quien domina el tema — la psicóloga, el auditor, el vendedor — puede abrir el documento, discrepar, corregir. Un método enterrado dentro de un prompt pasa a ser propiedad de quien escribe prompts, y así el proceso de la empresa termina dependiendo de alguien de tecnología para cambiar de opinión.

Una técnica que sale barata con esta arquitectura: hacer que el agente genere y, en el mismo turno, revise lo que generó contra el checklist del propio método. Generar sin revisar produce una pieza que pasa la vista y falla el criterio — y el modelo es mucho mejor encontrando lo que falta en un texto terminado que no olvidándose mientras escribe.

Sacale el cálculo de las manos al modelo#

Esta es la capa que separa el uso serio de la demostración, y se resume en una frase: si un número equivocado tiene consecuencias, ese número no puede salir de un modelo de lenguaje.

El Sistema Cuidar, que construimos para una consultora de salud y seguridad laboral, es el ejemplo directo. El informe tiene 15 secciones; la IA escribe cinco. La matriz de riesgo, la clasificación por factor y los gráficos se calculan del dato recolectado, de forma determinista — el modelo no los toca. Escribe la interpretación técnica sobre el resultado ya calculado. Eso es lo que hace que el documento sea firmable por una responsable técnica: ningún número del informe vino de un modelo de lenguaje.

La versión más barata de esta capa es la restricción por ausencia, y vale copiarla: no le des al modelo el dato que no puede usar. Nicky, el agente de atención que pusimos en el WhatsApp de la Agência OKSE, no habla de precios — no porque exista una instrucción que diga "no hables de precios", sino porque la agencia no tiene ningún servicio con precio de lista y, por lo tanto, no hay precio alguno en el material que ella lee. Su contenido se rehizo a partir del material oficial de la agencia: posicionamiento, servicios, preguntas frecuentes y los casos reales. Lo que no está ahí, no tiene forma de decirlo.

Una instrucción que prohíbe reduce la chance. La ausencia del dato elimina la posibilidad. Siempre que se pueda elegir la segunda, elegí la segunda.

La lista de lo prohibido — y el vocabulario que entra en su lugar#

Prohibir sin reemplazar no funciona. Un modelo instruido a "no usar lenguaje vago" produce otro lenguaje vago, porque no tiene con qué llenar el lugar. La lista que funciona tiene dos columnas: lo prohibido y lo obligatorio.

En el informe del Cuidar, el vocabulario superficial de recursos humanos está vetado — "mal clima", "liderazgo tóxico", "falta de resiliencia" — y la terminología ocupacional auditable está impuesta: "baja previsibilidad de las demandas", "ambigüedad de roles", "desequilibrio entre demandas y recursos". La misma lista prohíbe citar autores o referencias que no estén en el material entregado, que es la forma más común en que un texto técnico generado por IA se desarma en la primera revisión.

La ganancia no es solo de estilo. Una lista así es verificable: se puede buscar el término prohibido en el texto y saber, en segundos, si la regla se cumplió. Una instrucción subjetiva ("escribí con rigor técnico") no se verifica, y lo que no se verifica no se exige.

Lo que la instrucción no garantiza, el código sí#

Acá está la capa que casi nadie arma, y la más barata de todas.

Toda regla dentro de un prompt es un pedido. Un pedido bien escrito se cumple casi siempre — y "casi siempre" es una palabra que no sirve cuando la acción es irreversible. La prosa no es enforcement. Lo que nunca puede ocurrir necesita algo que lo detenga, no algo que lo pida.

Y no se trata solo de que el modelo falle por sí mismo. El OWASP Top 10 for Large Language Model Applications abre con LLM01: Prompt Injection — texto que llega de afuera puede redirigir el comportamiento del modelo. Es decir: la instrucción dentro del prompt es superficie de ataque, no garantía. Si la regla importa de verdad, no puede vivir en el mismo lugar por donde entra el contenido del usuario.

En nuestra operación esta capa es una política con una regla de una línea — interno y reversible es libre; externo o irreversible pide aprobación — más un freno en código que la aplica: intercepta la acción antes de que ocurra y pide aprobación en lugar de negar en silencio. Dos decisiones de diseño merecen una nota, porque son lo que mantiene vivo al freno en el día a día: pedir aprobación en vez de bloquear mantiene el trabajo fluyendo, y el freno es tolerante a su propia falla — si se rompe, el trabajo sigue, porque un freno que traba la operación se apaga en la primera semana y no vuelve nunca.

Del lado del cliente, la misma lógica aparece en decisiones banales. Nicky nunca inicia una conversación — no es una instrucción de buen comportamiento, es una operación diseñada para ser solo receptiva. Cada contacto tiene su propia fila, para que dos mensajes seguidos no generen dos respuestas. Y se identifica como asistente virtual cuando le preguntan — esta es la parte honesta de la historia: el prototipo le indicaba esquivar esa pregunta, y eso salió antes de que el agente entrara en operación. Lo descubrimos leyendo el prompt, no por el reclamo de un cliente.

La pregunta que resume la capa, y que vale hacer para cada "nunca" de tu lista: si el modelo lo hace igual, ¿cómo me entero? Si la respuesta es "por el cliente", la regla necesita código.

Cuándo no vale la pena restringir#

Restringir cuesta el trabajo de escribir el método, y hay casos en que ese costo no se paga:

• Cuando la tarea no tiene forma fija. Borrador, exploración, primera versión de una idea, resumen de reunión para uso propio. Ahí la variedad de la respuesta es su utilidad, e imponer una regla es burocracia.
• Cuando equivocarse no tiene consecuencias. Si el peor desenlace es que alguien lo rehaga, armar cuatro capas es demasiado caro para el riesgo.
• Cuando el proceso va a cambiar el mes que viene. Escribir método sobre terreno inestable produce un documento que nadie sigue: ni persona, ni modelo.

Y el límite honesto, que vale decir con claridad: restringir no hace que la salida esté bien. Hace que la salida sea auditable. La revisión humana sigue, y en contexto técnico sigue siendo de quien firma. Lo que cambia es dónde gasta el tiempo esa persona — en el Cuidar, la responsable técnica pasó a revisar y firmar en lugar de compilar planillas y tipear texto. Es un cambio grande, y no es lo mismo que ausencia de revisión.

También vale decir dónde estamos en deuda nosotros. El NIST AI Risk Management Framework, publicado por el instituto estadounidense de estándares en enero de 2023, organiza la gestión de riesgo de IA en cuatro funciones: Govern, Map, Measure y Manage. Las cuatro capas descritas acá cubren bien Govern y Manage: la regla está escrita y el freno existe. Measure es la que falta: medir sistemáticamente cuánto se adhiere al método lo que el modelo produce es trabajo que todavía no hicimos, y no conocemos a nadie en nuestro mercado que lo haya hecho. Quien esté armando esto ahora debería armar la medición junto, no después.

Por último, lo que estas capas no son: no exigen entrenar un modelo propio. El fine-tuning ajusta estilo y formato; no resuelve cuenta equivocada ni acción indebida, que son los dos problemas que sacan a una IA de un proceso serio.

Preguntas frecuentes#

¿Necesito entrenar un modelo propio para que siga mi proceso?#

En la mayoría de los casos, no. Entrenar ajusta el estilo y el formato de la respuesta, pero no garantiza que el cálculo esté bien ni que la acción prohibida no ocurra — y cuesta datos, tiempo y mantenimiento cada vez que el proceso cambia. Las cuatro capas que de verdad lo resuelven son de arquitectura: método escrito fuera del prompt, cálculo en código, lista de lo prohibido y un freno que detiene la acción. Nosotros trabajamos así todos los días, en producto interno y de cliente, sin entrenar ningún modelo.

¿Un prompt bien escrito no alcanza?#

Alcanza la primera semana. Lo que se rompe después es la duplicación: cuando el método está escrito dentro del prompt, existe en dos lugares, y el día en que la regla cambia en el documento el prompt sigue aplicando la versión anterior — en silencio, con apariencia de acierto. Por eso la regla vive fuera del prompt, en un documento único, y el agente recibe la instrucción de leer ese documento al ejecutar.

¿Cómo evito que la IA invente números?#

Sacándole los números de las manos. El cálculo es código: la cuenta, la clasificación y los gráficos salen del dato, de forma determinista, y el modelo escribe la interpretación sobre el resultado. Instruir al modelo a "no inventar datos" reduce el problema, pero no lo elimina: mientras pueda escribir un número, un número equivocado es una posibilidad. Cuando no puede, deja de serlo.

¿Se puede usar IA en un documento técnico que alguien va a firmar?#

Sí, con tres condiciones: ningún número del documento viniendo del modelo, fundamentación restringida a un material de referencia nombrado (sin citar autores que no estén en él) y revisión humana de quien firma. Lo que no cambia es la responsabilidad: sigue entera en quien firma. Lo que cambia es dónde gasta el tiempo esa persona: revisando en lugar de tipear.

¿Cuánto tarda restringir la IA a mi método?#

El cuello de botella no es técnico. Quien ya tiene el proceso escrito — de verdad, al nivel en que alguien nuevo podría ejecutarlo leyéndolo — arma las capas en días. Quien no lo tiene necesita el tiempo de escribir el método, y ese es el trabajo real. Por eso la pregunta correcta antes de contratar cualquier capa de IA es: ¿nuestra forma de hacer esto está escrita en algún lugar?

Fuentes#

• OWASP — "Top 10 for Large Language Model Applications", cuya primera entrada es LLM01: Prompt Injection — https://owasp.org/www-project-top-10-for-large-language-model-applications/
• NIST — "AI Risk Management Framework" (AI RMF), publicado en enero de 2023, con las funciones Govern, Map, Measure y Manage — https://www.nist.gov/itl/ai-risk-management-framework

Próximo paso#

Si estás evaluando poner IA en un proceso que tiene consecuencias, el primer movimiento no es elegir herramienta: es mirar si el método está escrito al nivel en que se puede exigir. Ese trabajo es el que sostiene las cuatro capas, y es lo que hacemos en IA y automatización — desde el informe técnico del Sistema Cuidar hasta el agente de atención de la Agência OKSE. Y si lo que tenés hoy es un producto ya construido por IA sin ninguna de estas capas, el tema es otro: qué se puede rescatar de un código generado por IA.