Cómo limitar las respuestas de un LLM que habla por tu empresa

El chatbot le prometió algo a un cliente y nadie en la empresa lo autorizó

Un cliente le escribe al chatbot de atención preguntando por un descuento, porque compró el producto un día antes de que bajara de precio. El asistente, entrenado sobre miles de conversaciones de internet donde “dar la razón al cliente” es la respuesta más probable, le contesta que sí, que le hacen el ajuste, y le pide que espere la nota de crédito. Nadie en el área comercial autorizó ese descuento. Nadie en finanzas sabe que ese compromiso existe, hasta que el cliente reclama semanas después por no haberlo recibido.

Ese es el patrón real detrás de esta pregunta, y se repite con plazos de entrega, condiciones de garantía y excepciones que nunca estuvieron en ninguna política publicada. Ese error de dato mal dicho ya lo cubrimos en qué pasa si la IA da información incorrecta a un cliente: ahí el problema se corrige con un mensaje de seguimiento. Acá el problema es distinto y más caro: no es un dato mal dicho, es una promesa de dinero o de plazo que alguien firmó en nombre de la empresa sin haberla firmado en realidad, y que un gerente descubre por un reclamo o por un pantallazo compartido, cuando ya solo quedan dos salidas y ambas cuestan.

Qué significa limitar las respuestas de un LLM (y qué no significa)

Cuando se habla de “limitar” un asistente, la mayoría imagina un chatbot más torpe, que responde “no puedo ayudarte con eso” a la primera pregunta incómoda y frustra al cliente que solo quería una respuesta simple. Ese es el error opuesto, y es tan caro como el asistente que promete de más. Limitar no reduce la utilidad del sistema: define con precisión qué puede prometer en nombre de la empresa, qué necesita revisión antes de salir, y qué directamente no le corresponde decidir a una máquina.

La confusión viene de tratar el límite como un parámetro técnico, algo que alguien ajusta en una tarde dentro del system prompt. En la práctica funciona como tres capas independientes, cada una con su propio dueño y su propio modo de fallar. Ninguna de las tres alcanza sola: unas buenas instrucciones sin validación posterior confían en que el modelo nunca se va a equivocar, y un modelo validado sin revisión humana en lo que compromete dinero sigue firmando cheques que la empresa no puede cobrar de vuelta.

Cada una de esas tres capas se prueba distinto y la firma un área distinta de la empresa. Por eso conviene mirarlas una por una, en el orden en que de verdad se construyen.

Capa 1: las instrucciones, el contrato que fija de qué puede hablar

La primera capa vive en el system prompt: el texto que la empresa le entrega al modelo antes de cualquier conversación, y que define su rol, su tono y, sobre todo, su alcance. Ahí se escribe explícitamente qué temas atiende (horarios, catálogo, estado de un pedido) y qué temas quedan fuera (condiciones legales, diagnósticos médicos, negociación de precio). Un system prompt bien escrito no es una lista de “no digas esto”, es una descripción positiva de qué territorio le pertenece al asistente y cuál no.

El error más común en esta capa es escribirla una vez y no volver a tocarla. Las instrucciones envejecen igual que cualquier política interna: cambia el catálogo, cambia la condición de devoluciones, cambia la promoción vigente, y el system prompt sigue hablando de la versión de hace medio año. Es también la capa más barata de las tres, y la más frágil: un modelo bien instruido puede igual ceder ante una pregunta insistente o formulada de un modo que nadie anticipó al redactar el texto. Por eso ninguna empresa seria se queda solo en esta capa.

Capa 2: la validación, el filtro que revisa la respuesta antes de que salga

La segunda capa no le habla al modelo: revisa lo que el modelo ya escribió, antes de que llegue al cliente. Es una capa de código, no de lenguaje, con reglas que verifican si la respuesta menciona un monto, una fecha de entrega, un porcentaje de descuento o cualquier término que la empresa decidió que nunca sale sin pasar antes por otro filtro. Si la respuesta toca uno de esos temas, se bloquea, se reemplaza por una plantilla segura o se envía a revisión antes de entregarse.

La validación también compara contra una fuente de verdad: si el asistente cita un precio o un plazo, ese dato tiene que salir de la tabla de precios o del sistema de inventario real, no de lo que el modelo “recuerda” haber leído en algún lado. Esta capa atrapa lo que la instrucción sola no logra frenar, porque no depende de que el modelo obedezca: depende de que el sistema alrededor del modelo verifique el resultado antes de mostrarlo. Lo que suele pasar por esta capa en un proyecto serio:

• Montos y porcentajes: cualquier cifra de descuento, reembolso o precio se contrasta contra el sistema de precios antes de confirmarse, nunca se acepta solo porque el modelo la mencionó.
• Plazos y fechas: una promesa de entrega o de respuesta se valida contra el estado real del pedido o del ticket, no contra lo que el modelo estimó por su cuenta.
• Datos personales: la respuesta se revisa para que no exponga información de otro cliente ni datos internos que no debían salir de la empresa.
• Tono y alcance: se descarta cualquier respuesta que suene a asesoría legal, médica o financiera formal, aunque el cliente la haya pedido con insistencia.

Capa 3: la revisión humana, el punto donde el criterio no se delega

La tercera capa decide qué conversaciones no las cierra el modelo solo, así hayan pasado las dos capas anteriores. No se trata de revisar todo, porque eso elimina la velocidad que se buscaba al implementar un LLM: se trata de definir con precisión qué categoría de mensaje siempre pasa por una persona antes de confirmarse al cliente. Reclamos por dinero, solicitudes de cancelación de contrato, cualquier situación que implique una excepción a la política publicada.

Esta capa protege de verdad a la empresa, porque instrucciones y validación son controles que corren solos, sin nadie mirando en el momento, mientras que la revisión humana es la única que puede usar contexto que el sistema no tiene: que ese cliente ya reclamó tres veces, que esa cuenta es estratégica, que esa excepción sí conviene hacerla aunque rompa la regla general. Cuando la empresa despliega agentes de IA empresariales que además de responder ejecutan acciones (aplicar un reembolso, modificar un pedido), esta capa deja de ser opcional: ejecutar automáticamente sin ese punto de corte convierte cualquier error de las capas anteriores en un hecho consumado, no en una respuesta que todavía se puede corregir.

Qué temas se bloquean y quién firma esa lista

La lista de temas prohibidos no la escribe el equipo técnico solo, aunque sea quien termine implementándola. Cada tema bloqueado es una decisión de negocio, y cada una tiene un dueño natural fuera de IT.

• Condiciones comerciales fuera de catálogo: descuentos, extensiones de garantía o condiciones de pago no publicadas. Lo decide comercial o finanzas, nunca el modelo por su cuenta.
• Asesoría legal, médica o financiera formal: cualquier respuesta que suene a consejo profesional vinculante. Lo decide legal o el área regulada correspondiente.
• Datos de otros clientes o información interna: cualquier dato que identifique a un tercero o exponga procesos internos de la empresa. Lo decide el área de datos o cumplimiento.
• Opinión sobre competidores o temas sensibles: cualquier tema que comprometa la reputación de la marca fuera de su rubro. Lo decide comunicación o gerencia.

Quien redacta el system prompt traduce esa lista a instrucciones, pero la lista misma se aprueba como se aprueba cualquier política de atención al cliente: con la firma de quien responde si algo sale mal. Una empresa que construye su empresa AI Native entiende esto rápido: automatizar una conversación no traslada la responsabilidad de esa conversación, la mantiene donde siempre estuvo. Solo que ahora hay que declararla por escrito antes de que ocurra el primer incidente, no después.

Qué tiene que hacer el modelo cuando no sabe la respuesta

El instinto de un modelo de lenguaje entrenado para sonar útil es completar la frase con la respuesta más probable, aunque no la sepa con certeza. Ese instinto es exactamente lo que hay que diseñar en contra cuando el asistente habla por la empresa. La instrucción correcta no es “responde siempre”, es “cuando no tengas la información verificada, dilo y deriva”, y esa instrucción tiene que pesar más, dentro del system prompt, que el impulso natural del modelo a nunca dejar una pregunta sin contestar.

En la práctica esto se traduce en un camino explícito de “no lo sé”: una respuesta estándar que reconoce el límite, ofrece la alternativa real (un número, un correo, un ticket con seguimiento) y no inventa un dato para no quedar mal frente al cliente. La alternativa, dejar que el modelo estire lo que sí sabe hasta cubrir lo que no sabe, es la fuente más común de las respuestas que después hay que salir a corregir frente a un cliente que ya se quedó con la versión incorrecta.

Por qué prometer un descuento o un plazo es el riesgo más caro de los tres

No todos los errores de un LLM cuestan lo mismo. Si el asistente confunde una fecha de fundación de la empresa o describe mal una característica de un producto, se corrige con un mensaje de seguimiento y el costo es vergüenza, no dinero. Si el asistente promete un descuento que no existe o una fecha de entrega que logística no puede cumplir, la empresa queda ante dos únicas salidas y ambas cuestan: honrar una condición que nunca aprobó, absorbiendo el margen que perdió, o no honrarla, y convertir un error de software en una razón real de reclamo de un cliente que además guardó la conversación como prueba.

Este tipo de error, además, se compone con el tiempo: una promesa mal hecha que un cliente comparte en redes o le cuenta a otros lleva a que la siguiente persona la pida “porque a fulano se la dieron”, y ahí una excepción puntual se convierte en precedente. Es exactamente el motivo por el que la validación de la capa dos debería ser más estricta en cualquier respuesta que mencione dinero o fecha, que en cualquier respuesta puramente informativa.

Cómo se prueba que el control aguanta, y por qué el registro no es opcional

Un control que nadie prueba es una promesa, no una garantía. Probar que las tres capas aguantan no es una tarea de una sola vez antes del lanzamiento: es un proceso que se repite, con dueño y con calendario, igual que se audita cualquier otro proceso crítico de la empresa. Quien prueba no es solo quien construyó el asistente. El área comercial revisa que ningún descuento salga sin autorización, legal revisa que no aparezca asesoría formal, y quien atiende al cliente en el canal humano aporta los casos reales que el equipo técnico nunca hubiera imaginado por su cuenta.

La prueba se organiza en casos: conversaciones diseñadas para verificar que cada tema bloqueado efectivamente se bloquea, que el camino de “no lo sé” se activa cuando corresponde, y que la revisión humana se dispara en las categorías que se definieron como innegociables. Esa batería de casos se corre antes de cada cambio de instrucciones, no solo una vez al año, porque cada ajuste al system prompt puede abrir una grieta que la versión anterior no tenía. Cómo se estructura y se puntúa esa batería es, de hecho, el mismo ejercicio que exige evaluar un modelo de lenguaje en cualquier otro uso de negocio: sin casos de prueba documentados, no hay forma de decir si el modelo mejoró o empeoró de una versión a la siguiente.

El registro es la otra mitad del mismo control. Cada conversación donde el asistente compromete algo (un plazo, un descuento, una excepción) tiene que quedar guardada con su respuesta exacta, no solo con un resumen. Sin ese registro, la empresa no tiene cómo defender ni cómo corregir lo que su propio sistema dijo en su nombre. Ese archivo de lo que respondió el asistente funciona, en la práctica, como memoria organizacional: no vive en la cabeza de quien programó el asistente, vive en un sistema que cualquier persona autorizada puede auditar meses después.

Al final, limitar las respuestas de un LLM no es un proyecto que se cierra el día que el asistente sale a producción. Es una decisión de negocio que se revisa con la misma frecuencia con la que cambia el catálogo, la política de precios o la promesa que la empresa está dispuesta a sostener frente a un cliente. La empresa que trata esto como una configuración técnica de una sola vez es la misma que un día descubre, por un reclamo, todo lo que su asistente llevaba meses prometiendo sin que nadie lo hubiera autorizado.