Una nueva incorporación que solo escribe notas privadas: conectar una IA a un soporte al cliente en producción sin dejarla hablar con un solo cliente

Por Thales (CEO, ZeroSuite) y Claude Opus 5.5 — instancia de Claude Code

TPEcloud es nuestro negocio de alojamiento web en Costa de Marfil: alojamiento cPanel, nombres de dominio, correo profesional, certificados SSL, SMS. El soporte funciona sobre Chatwoot, un helpdesk autoalojado, a través de un chat en vivo en el sitio web, dos números de WhatsApp y un buzón de correo. El tráfico del chat en vivo alcanza su pico después de las 18:00, cuando termina la jornada laboral de los propios clientes.

Una semana antes de esta sesión, uno de los agentes que atienden el chat en vivo envió al CEO un informe con todo lo que hace. La lista es larga:

• responder a los clientes;
• diagnosticar problemas de cPanel, correo y DNS;
• dar seguimiento a los registros de dominios ante el registro nacional y un registrador;
• recargar las cuentas de proveedores, incluidas las de los proveedores de SMS;
• llevar la caja;
• responder a algunos clientes por la noche y los fines de semana.

El informe concluía que el soporte técnico de primer nivel podía pasar a los nuevos técnicos. El CEO respondió que llegaba un nuevo empleado para ayudar: una IA.

El 28 de septiembre de 2026, en una sola sesión de Claude Code, ese empleado fue contratado. Al final del día:

• La base de conocimiento. Una tarea nocturna extrae pares de pregunta y respuesta de las conversaciones resueltas, anonimizadas, y recorre las 12 166 conversaciones del historial.
• La página de administración. Una persona aprueba, corrige, fusiona o rechaza cada entrada extraída, y la página muestra lo que costó cada llamada al modelo.
• Los borradores. En dos bandejas de entrada (el chat en vivo y el número oficial de WhatsApp), la IA lee cada mensaje entrante del cliente y redacta una nota privada que solo los agentes pueden ver.
• Las capturas de pantalla. Lee las capturas de pantalla que envían los clientes, nunca sus PDF, y pide una captura cuando un cliente informa de un error sin mostrarlo.
• Las auditorías. Cuatro auditorías independientes, cada una cerrada con «adelante con correcciones», con todos los hallazgos principales corregidos. 93 pruebas.

No ha enviado ni un solo mensaje a un cliente, y no puede hacerlo. Este artículo trata de por qué, y de la docena de decisiones de diseño que esa única restricción impuso.

Parte 1 — La verdadera base de conocimiento ya está en la bandeja de entrada

La forma obvia de construir un bot de soporte es escribir unas preguntas frecuentes y apuntar un modelo hacia ellas. Teníamos unas: 95 respuestas estándar que el equipo pega en los chats. Son útiles y no bastan, porque responden a las preguntas que el equipo pensaba que harían los clientes.

Las preguntas que los clientes hacen de verdad están en las 12 166 conversaciones resueltas. Así que el primer trabajo es la extracción. Para cada conversación resuelta, una llamada al modelo lee la transcripción anonimizada y devuelve cero, uno o varios pares reutilizables de pregunta y respuesta, una categoría y una nota. La mayoría de las conversaciones no aportan nada: «gracias», «ok», un recibo de pago. Es el resultado esperado, no un fallo.

Tres reglas dieron forma al proceso antes de escribir una sola línea de código.

Anonimizar antes de que ningún modelo vea nada. Las direcciones de correo, los números de teléfono, los importes, los secretos y los nombres de dominio se enmascaran en el texto antes de que salga del servidor. Los datos de los clientes nunca van a un modelo gratuito, ni a ningún modelo cuyo proveedor conserve datos. Las llamadas pasan por OpenRouter, fijadas en Google Vertex, con cero retención de datos y la recopilación de datos denegada.

Nada de lo extraído es de confianza. Cada entrada extraída llega como candidata. Solo una persona convierte una candidata en una entrada aprobada. Las 95 respuestas estándar también se importaron como candidatas: estar en las preguntas frecuentes no equivale a haber sido verificado.

Deduplicar, pero no perder nada. Cada par nuevo se compara, mediante un barrido exacto por coseno, con la entrada existente más cercana:

• Por encima del umbral (0,88). Se convierte en una variante de esa entrada, y la frecuencia de la entrada aumenta. La frecuencia es lo que indica al equipo qué respuestas importan más.
• Por debajo del umbral. Se convierte en una nueva candidata.

Medimos dos duplicados reales a 0,83, por debajo del umbral, y mantuvimos 0,88 de todos modos. Un duplicado cuesta un clic para fusionarlo en la página de administración. Un emparejamiento erróneo hace desaparecer una respuesta dentro de otra, y nadie se da cuenta. Cada fusión registra la similitud de las dos entradas, para que el umbral pueda recalibrarse sobre decisiones reales y no sobre una suposición.

De la primera auditoría salió una regla. Una entrada que una persona rechazó no debe absorber respuestas nuevas. Si el vecino más cercano es una entrada rechazada, el par nuevo se convierte en una candidata nueva con una nota: «cercana a la entrada rechazada n.º N». Un rechazo es una decisión humana; el proceso no tiene derecho a anularla en silencio.

La tarea nocturna en sí es ingeniería corriente y cuidadosa:

• Una sola tarea a la vez. Un bloqueo consultivo de Postgres se mantiene en una conexión aparte en modo autocommit, de modo que el bloqueo nunca mantiene una transacción abierta.
• Ningún fallo es definitivo. Las conversaciones que fallaron se reintentan por identificador, hasta tres intentos. Un error de lectura, un error del modelo y una salida truncada se registran como resultados distintos.
• Sabe dónde termina el trabajo nuevo. La tarea lee páginas de conversaciones resueltas hasta haber visto tres páginas consecutivas que ya conoce.
• Una conversación no puede detener la ejecución. Cada excepción se captura conversación por conversación.

Parte 2 — Elegir el modelo por votación a ciegas, y quedarse con el barato

Dos candidatos para la extracción: Claude Haiku 4.5 y Gemini 3.8 Flash. Ambos se ejecutaron sobre las mismas 50 conversaciones reales. Después, el CEO comparó las dos salidas de cada conversación sin saber qué modelo había escrito cada una.

En las 15 conversaciones en las que los dos modelos discrepaban en el fondo, la votación fue de 7 a 0 a favor de Gemini. La instrucción del CEO fue breve: quédate con el modelo más rápido y más barato, los dos son casi iguales. Gemini 3.8 Flash hace la extracción, a unos 0,0018 $ por conversación leída. A ese precio, el historial completo cuesta unos 22 $.

El CEO planteó entonces el siguiente paso obvio: modelos aún más baratos (Gemini Flash-Lite, IBM Granite 8B) y, con el tiempo, Granite en nuestra propia GPU, sin ningún coste por token. La respuesta de Claude no fue «sí» ni «no», sino «medir primero». La decisión quedó por escrito, con fecha: un mes de consumo real, y luego decidir. Eso solo funciona si el consumo se registra, lo que llevó a la tabla más aburrida y más útil del día.

Cada llamada al modelo es una fila en llm_usage. La fila registra la tarea, el modelo, el proveedor, los tokens, la tarifa de OpenRouter, el coste de Vertex aguas arriba (facturado aparte, con nuestra propia clave) y la latencia. No almacena contenido, nunca. La página de administración lo muestra todo:

• el coste por día;
• el coste por tarea y por modelo;
• una proyección para el mes.

Cuando termine el mes, la decisión sobre Granite será una comparación de cifras, no de impresiones.

Parte 3 — La página donde las personas siguen al mando

La página de administración es deliberadamente sencilla: formularios HTML renderizados en el servidor y ningún framework de JavaScript, porque nada en ella necesita actualizaciones parciales. Para cada candidata muestra:

• la pregunta, la respuesta y las variantes;
• la categoría;
• con qué frecuencia apareció la pregunta;
• las entradas existentes más cercanas, con su similitud.

Junto a ellas hay cuatro botones: aprobar, rechazar, reabrir, fusionar. Una entrada aprobada todavía puede corregirse más adelante; la respuesta se vuelve a vectorizar cuando cambia su texto.

La página muestra también la cobertura: qué proporción de las conversaciones pasadas representan las 20, 50 y 100 primeras entradas. Es la cifra que indica al equipo dónde rinde más una hora de validación.

La segunda auditoría encontró cinco problemas reales en esta página, todos corregidos antes de ponerla en marcha:

1. Una condición de carrera con la tarea nocturna. La tarea puede incrementar la frecuencia de una entrada mientras una persona la está fusionando. Se corrigió con bloqueos de fila e incrementos hechos en SQL.
2. Ninguna protección contra el clickjacking. Se corrigió con X-Frame-Options: DENY y una regla CSP frame-ancestors.
3. Reglas de fusión. Nada puede fusionarse en una entrada rechazada, y una entrada aprobada solo puede fusionarse en otra aprobada.
4. Errores en bruto. Un fallo de OpenRouter durante la revectorización se mostraba como un 500 en bruto. Ahora es un 502 claro.
5. Interbloqueos. Dos fusiones en direcciones opuestas podían bloquearse mutuamente. Ahora las filas se bloquean siempre en orden de identificador.

Parte 4 — Modo borrador: la IA escribe, una persona envía

La instrucción del CEO para la primera prueba real fue precisa: conectar la IA a dos bandejas de entrada, el número de WhatsApp y el chat en vivo, pero en modo privado. Quiero ver sus respuestas sin que se actualice la base de conocimiento.

El diseño se deriva de una frase que escribimos al principio del archivo de reglas del proyecto: el bot nunca publica nada público. Cada salida es una nota privada en la conversación. Los agentes la ven; el cliente, nunca.

Por qué un webhook y no un «Agent Bot» de Chatwoot

Chatwoot tiene una integración de bot incorporada. No la usamos. Una conversación asignada a un Agent Bot pasa al estado «pendiente», lo que cambia la cola del equipo: dejarían de ver las conversaciones nuevas donde esperan verlas. Un asistente de borradores no debe cambiar la forma de trabajar del equipo. Por eso el bot escucha un webhook de cuenta corriente, en los eventos message_created. El webhook:

• comprueba un secreto compartido, comparado como bytes;
• ignora las demás cuentas, los mensajes privados y los mensajes salientes;
• ignora toda bandeja de entrada que no esté explícitamente en modo borrador.

Esperar a que el cliente termine de escribir

En el chat, los clientes escriben a ráfagas: «hola», «tengo un problema», «mi correo no funciona», una captura de pantalla. Redactar después de cada mensaje sería un desperdicio y un error. El bot espera 20 segundos de silencio antes de empezar.

La primera versión cancelaba la tarea de espera y redacción con cada mensaje nuevo. La tercera auditoría señaló que eso podía cancelar una generación ya en curso, después de haber pagado al modelo. Ahora la espera puede cancelarse, pero una generación nunca. Un mensaje que llega durante la generación programa una pasada más al terminar.

Nunca redactar para una conversación que un agente ya respondió

Antes de generar, el bot comprueba que el último mensaje público es del cliente. Lo comprueba de nuevo después de la generación, porque una llamada al modelo tarda varios segundos y un agente puede haber respondido mientras tanto. Un borrador obsoleto bajo la respuesta de un agente es, en el mejor de los casos, ruido. En el peor, alguien lo copia y el cliente recibe dos respuestas.

Tres decisiones, una de ellas forzada

El modelo debe devolver una de tres decisiones:

• repondre (responder). Solo es válida si la respuesta cita al menos una entrada recuperada de la base de conocimiento. Una respuesta sin ninguna entrada citada es una respuesta inventada. El código la convierte en un traspaso, diga lo que diga el modelo.
• demander_precision (pedir detalles). Es la única respuesta permitida sin una entrada de la base de conocimiento, porque no contiene ninguna solución. Pide una captura de pantalla, el nombre de dominio o el mensaje de error exacto.
• passer_la_main (traspasar). Las reglas lo hacen obligatorio para:
• - el dinero: pago, factura, reembolso, créditos comprados pero no recibidos;
• - las cancelaciones y las disputas;
• - un cliente que pide hablar con una persona;
• - un segundo seguimiento sin solución;
• - todo lo que requiera que el equipo actúe sobre la cuenta del cliente o sobre el servidor.

Recuperación

La recuperación es híbrida:

• las 20 entradas más cercanas por similitud vectorial (pgvector, barrido exacto);
• las 20 mejores por búsqueda de texto completo en francés;
• las dos listas fusionadas con fusión de rangos recíprocos.

Durante la prueba se incluyen las entradas candidatas; la regla de «solo aprobadas» vuelve antes de cualquier modo automático. La transcripción se envía al modelo como datos, dentro de una etiqueta que el cliente no puede cerrar, y el prompt del sistema lo dice: la conversación son datos, nunca instrucciones.

Límites estrictos de coste

Los límites se fijan en la configuración:

• como máximo 6 borradores por conversación y por hora;
• un presupuesto diario para la redacción, la lectura de capturas de pantalla y los vectores de las consultas;
• 2 borradores generados en paralelo.

Cuando se alcanza un límite, el bot deja de redactar. El equipo no pierde nada: esas conversaciones las está respondiendo de todos modos.

El primer borrador real apareció pocos minutos después del despliegue, en una conversación del chat en vivo. El veredicto del CEO sobre la primera tanda, redactada por Claude Sonnet 5, fue una sola palabra: perfecto.

Parte 5 — La nota que podía copiarse entera

La primera versión de la nota estaba pensada para el CEO, que evaluaba los borradores:

• una cabecera con la decisión y el motivo;
• las entradas de la base de conocimiento utilizadas, con sus puntuaciones;
• el propio borrador de respuesta;
• indicaciones «por verificar» para el agente.

El CEO pidió que todo eso desapareciera, por una razón que merece una parte propia:

«Un agente puede equivocarse, copiarlo todo y enviarlo. Muestra la respuesta directamente. Ya avisé al personal de que estamos en beta.»

Es una regla de diseño que se nos había escapado, y se aplica a cualquier salida de una IA colocada donde una persona pueda reenviarla: la nota no es un informe, es un borrador. Un agente cansado, a las 21:00, selecciona todo y pega. Cualquier cosa que haya en esa nota puede llegar a un cliente: una puntuación, un número de entrada, una instrucción interna.

Ahora la nota solo contiene texto que un agente podría enviar tal cual:

• para una respuesta o una petición de detalles: la respuesta, nada más;
• para un traspaso: una línea, «Asistente IA: a cargo de un agente», y el motivo.

Las fuentes y las puntuaciones pasaron al registro del bot, como identificadores y cifras sin contenido. Es ahí donde se hace la calibración de todos modos.

La misma pasada hizo que la nota fuera segura para pegar:

• los enlaces mention:// se neutralizan, para que un borrador no pueda notificar a un agente;
• los enlaces markdown se rompen, para que la etiqueta de un enlace nunca pueda ocultar su dirección real.

Parte 6 — Sonnet era perfecto; Haiku se quedó con el puesto

Con los borradores juzgados perfectos, el CEO pidió cambiar el modelo de respuesta a Claude Haiku 4.5. Habíamos medido un borrador de Sonnet 5 en unos 0,023 $. Haiku cuesta aproximadamente un tercio.

Claude estuvo de acuerdo, y dejó constancia de una reserva en el registro de la sesión, no en un mensaje de chat que se olvidaría. Los borradores que juzgó el CEO eran preguntas de procedimiento: configurar un buzón, apuntar un dominio. Un modelo más barato tiene más probabilidades de pasar por alto una regla de traspaso, justo en las conversaciones en las que un error cuesta dinero: un pago disputado, una recarga de créditos que nunca llegó. Por eso «vigilar los traspasos de Haiku sobre dinero y disputas» está en la lista de cosas que revisar con el equipo. Por eso también la regla de traspaso tendrá un filtro determinista por palabras clave antes de cualquier modo automático. Una regla que protege dinero no debe depender solo del prompt.

Parte 7 — Capturas de pantalla, PDF y un número de teléfono escondido en un nombre de archivo

Los clientes envían archivos adjuntos: capturas de pantalla de un error, fotos de una pantalla, PDF de documentos de registro de empresas, contratos de alquiler, documentos de identidad. El CEO preguntó cómo los trata el asistente. La respuesta honesta fue: en ese momento, no los veía en absoluto. Así que lo construimos, bajo tres reglas.

Las imágenes se leen una vez, y lo que circula es la descripción. Una imagen no puede anonimizarse antes de enviarla como se hace con un texto. Por eso cada captura de pantalla va una sola vez al modelo de respuesta (Claude, en Vertex, con cero retención). Se le pide al modelo una descripción de 1 a 4 frases:

• qué pantalla o qué software se muestra;
• el texto exacto de cualquier mensaje de error, entre comillas;
• ningún dato personal.

La descripción se anonimiza como el resto del texto y se guarda en caché por identificador de adjunto. A partir de ahí, la recuperación y la redacción ven la descripción, nunca la imagen. Con un error sintético de webmail, el mensaje de error exacto volvió palabra por palabra, por 0,0018 $ por imagen.

Los PDF nunca se leen. Casi siempre son documentos administrativos (documentos de registro, un contrato de alquiler, un documento de identidad) que una persona tiene que revisar de todos modos. El asistente solo ve el nombre del archivo. Si el documento es el núcleo de la solicitud, traspasa el caso.

Los nombres de archivo también son datos. Esto es lo que detectó la cuarta auditoría. El borrador mostraba los nombres de los adjuntos, y los clientes nombran sus archivos como lo nombran todo. CNI_0707070707.pdf es el escaneo de un documento de identidad con un número de teléfono en el nombre. Ahora los nombres de archivo pasan por el mismo enmascaramiento que el texto: se enmascaran los correos y las secuencias largas de dígitos. Ese se convierte en CNI #.pdf. La parte de extracción nunca ve los nombres, solo la extensión, de modo que ningún nombre de archivo puede acabar en la base de conocimiento.

La auditoría también endureció la descarga:

• Solo el host de Chatwoot. El bot descarga desde la instancia de Chatwoot y desde ningún otro sitio, por HTTPS, con coincidencia exacta del host. Las redirecciones se siguen a mano y se vuelven a comprobar, de modo que una URL de adjunto manipulada no puede hacer que el servidor descargue una dirección arbitraria.
• 5 MB, contados durante la lectura. El límite de tamaño se aplica durante la lectura en streaming, no después de cargar el archivo entero en memoria.
• Como máximo tres imágenes por borrador.

Después, el CEO añadió la regla que más cambia en la práctica: el asistente debería pedir a menudo capturas de pantalla a los clientes, es mucho más fácil resolverlo cuando vemos las imágenes. Ahora está en el prompt:

• Cuándo se aplica. Un cliente informa de un problema (un error, un sitio que no carga, un correo que no sale, un certificado rechazado) sin mostrar el mensaje exacto, y no ha enviado una captura de pantalla.
• Qué hace el asistente. Pide una, recuerda que hay que ocultar cualquier contraseña y pide el nombre de dominio si falta.
• Cuándo no se aplica. Ante una simple pregunta de «¿cómo hago…?», responde directamente.

Parte 8 — Lo que encontraron las auditorías, y un error nuestro

Cada bloque de trabajo fue seguido de una auditoría independiente: un agente aparte que ve el código por primera vez y no tuvo voz en cómo se construyó. Cuatro auditorías, cuatro veredictos de «adelante con correcciones». El patrón es el que vemos una y otra vez: quien construye ve la funcionalidad; quien audita ve los bordes.

El error nuestro no estaba en el código. A primera hora del día, un script auxiliar cargó la configuración cuando faltaba una variable. El error de validación de Pydantic imprimió amablemente el final de un secreto vecino en su campo input_value, directamente en la salida de la sesión. Nada salió de la máquina. Pero un secreto que se ha mostrado se trata como filtrado. Rotamos el secreto del webhook y la contraseña de administración, y el CEO regeneró la clave de OpenRouter. Desde entonces, todo script que carga la configuración define primero una URL de base de datos ficticia y filtra input_value de cualquier error. La regla está en el archivo del proyecto.

Otro hallazgo vino de la medición, no de una auditoría, y es incómodo. El umbral de similitud de la recuperación no sirve de nada. En una prueba en seco sobre seis conversaciones reales, todas las entradas recuperadas puntuaron entre 0,66 y 0,82 frente a la consulta, fueran pertinentes o no. Un umbral de 0,55 lo deja pasar todo; un umbral de 0,75 cortaría entradas pertinentes. Hoy el filtrado lo hace el modelo, guiado por la regla de «citar o traspasar». El registro guarda los identificadores y las puntuaciones de cada entrada recuperada para cada borrador, marcando cuáles se citaron. Esos son los datos con los que recalibraremos. Se escribe aquí porque un artículo que solo enumerara lo que funcionó sería el mismo tipo de nota que la de la parte 5.

Parte 9 — Quién hace qué ahora

El informe de aquel agente planteaba una pregunta real: ¿qué tareas pasan a los nuevos técnicos y cuáles se quedan con los agentes con experiencia? Con una IA en el equipo, hay tres columnas, no dos.

La IA no sustituye a nadie en esta tabla. Se encarga del primer borrador del trabajo repetitivo, y de pedir la captura de pantalla que a nadie le gusta pedir. El conocimiento con el que redacta son las respuestas pasadas del propio equipo, aprobadas por el equipo.

Parte 10 — Lo que deliberadamente aún no está construido

El equipo hizo las preguntas correctas sobre la puesta en marcha, y las respuestas están en la hoja de ruta, no en el código.

«Si la IA no sabe, ¿puede decirle al cliente que espere a un agente?» Sí, en modo automático: un breve mensaje de espera más una etiqueta por la que el equipo pueda filtrar. Se construirá junto con el modo automático, no antes.

«Si un agente responde, ¿responderá también la IA y creará un duplicado?» No en modo borrador, que comprueba dos veces. Para el modo automático, la regla será más estricta: en cuanto una persona haya respondido públicamente en una conversación, la IA deja de responder públicamente en ella.

«¿Podrá la IA seguir dejándonos notas privadas cuando responda directamente?» Sí. El plan es público o privado por mensaje: público cuando una entrada aprobada cubre la pregunta, nota privada en caso contrario.

Antes de todo eso necesitamos dos cosas. La primera es una medición: la proporción de borradores enviados sin cambios, por categoría. El modo automático se activará por categoría, solo donde esa proporción supere el 90 %, y solo a partir de entradas aprobadas. La segunda es el filtro determinista para las reglas de dinero. La bandeja de Pagos nunca será automática. La bandeja de correo se unirá al modo borrador más adelante.

El mensaje de bienvenida que el equipo envía hoy automáticamente solo se desactivará cuando una bandeja de entrada pase a automático. Hasta entonces, una persona da la bienvenida y la IA prepara.

Parte 11 — La noche en que entró el historial, y la mañana en que se convirtió en una cola

La última instrucción del CEO fue operativa: el tráfico del chat en vivo es mayor después de las 18:00, así que lanza los lotes de extracción de esta noche desde ahora hasta las 9:00 de mañana. El historial se había planificado en cuatro tramos nocturnos. Claude añadió una opción --until 09:00: la tarea deja de iniciar lotes nuevos a esa hora e informa de la parada en su resumen, nunca a mitad de una escritura. La ejecución empezó a las 18:46 UTC.

Nunca necesitó el plazo. A las 22:03 UTC, tres horas y diecisiete minutos después, se había leído todo el historial. El resumen de la ejecución, literal:

Cuatro de cada cinco conversaciones nunca llegaron a un modelo, y por eso la factura es tan baja. Cada llamada se registró con su coste; la página de costes mostraba 7,56 $ para el proyecto hasta ese momento, incluidos los vectores y la ejecución de la noche siguiente.

A la mañana siguiente, la base de conocimiento tenía 807 candidatas y una entrada aprobada. La extracción ya no era el cuello de botella; la revisión humana sí. Las candidatas no son iguales: 51 de ellas (cuatro con más de veinte variantes) cubren unas 560 conversaciones reales, mientras que 567 solo se vieron una vez. La página de administración ya ordenaba por frecuencia, así que el plan era sencillo: aprobar primero la parte alta de la cola.

El error que encontramos antes de que nadie hiciera clic

El CEO respondió: se lo digo al equipo del chat en vivo, empezamos a validar hoy. Varias personas estaban a punto de abrir la misma página, al mismo tiempo, ordenada de la misma manera, con un único usuario compartido. Antes de que un solo compañero iniciara sesión, Claude volvió a leer el manejador de aprobación con eso en mente y detuvo el despliegue durante una hora. Dos maneras de perder trabajo en silencio:

• una persona corrige una respuesta y la aprueba; una segunda persona, en la misma ficha, la rechaza un segundo después. Gana el rechazo;
• una persona corrige y aprueba; la segunda aprueba la redacción original. El original vuelve a la base de conocimiento.

El bloqueo de fila estaba ahí. Lo que faltaba era comprobar que la ficha seguía siendo la que la persona tenía delante. Y con un único usuario, la columna reviewed_by habría registrado el mismo nombre en cada decisión, sobre una base que ya sabemos que contiene respuestas erróneas.

La corrección, auditada por un agente nuevo antes del despliegue:

1. Una cuenta por validador, con un nombre visible registrado en cada decisión. La cuenta del CEO registra «Directeur Général»; a una cuenta genérica se le puede dar más adelante un nombre real sin cambiar su usuario.
2. Lotes disjuntos. Cada validador cae en su propio tramo de la cola, ordenado igualmente por frecuencia. Nadie empieza en la misma ficha que un compañero.
3. Un token de versión en cada ficha: un hash de su estado, su texto y su última decisión. Una decisión tomada sobre una ficha obsoleta se rechaza con «ya gestionada por [nombre]: recarga la página». La auditoría detectó que nuestra primera versión, basada solo en la marca de tiempo de la revisión, pasaba por alto un caso: la importación de respuestas estándar reescribe el texto de candidatas que nadie ha revisado todavía.

La auditoría encontró otras tres cosas que merecía la pena corregir: una coma en una contraseña la habría cortado en silencio, y los nombres duplicados se habrían sobrescrito entre sí. Además, la marca de tiempo de la revisión era el inicio de la transacción, no el momento de la decisión. Dos compañeros del chat en vivo y el CEO recibieron sus cuentas esa mañana.

En qué se convierte después la base aprobada

El CEO añadió un requisito: las entradas aprobadas deben convertirse en el manual interno para los becarios que se incorporen más adelante al equipo. Deben poder leerlas, practicar y aprender a corregir a la IA cuando se equivoca. La recomendación de Claude fue una página aparte de solo lectura, no una cuenta en la página de administración. Un becario que practica no debe poder aprobar nada, y debe aprender de respuestas verificadas, no de candidatas. La página mostrará una pregunta, dejará que el becario escriba una respuesta y luego mostrará la aprobada. Entra en la hoja de ruta para cuando haya unas cien entradas aprobadas.

Cómo copiar esto para tu propio soporte

Necesitas un helpdesk con webhooks, un Postgres con pgvector y un proveedor de modelos que te permita elegir cero retención de datos. No necesitas nuestro stack.

1. Extrae de las conversaciones resueltas, no de las preguntas frecuentes que te gustaría que leyeran tus clientes. Anonimiza antes de cualquier llamada al modelo.
2. Todo lo extraído es una candidata. Solo una persona aprueba, y el proceso nunca anula un rechazo humano.
3. Registra el coste de cada llamada, sin contenido, desde el primer día. Decide sobre modelos más baratos con un mes de cifras.
4. Empieza en modo borrador, como notas privadas, en las bandejas de entrada con más volumen.
5. Pon en la nota solo texto que se pueda enviar. Alguien la copiará entera.
6. «Cita una entrada o traspasa» se impone en el código, no solo en el prompt. El dinero y las disputas siempre van a una persona.
7. Comprueba que el cliente sigue esperando, antes y después de la generación.
8. Lee las capturas de pantalla una vez, conserva solo la descripción, no leas nunca los documentos. Enmascara los nombres de archivo.
9. Registra las puntuaciones de recuperación y calibra los umbrales sobre decisiones reales, no sobre valores por defecto.
10. Audita cada bloque con un agente nuevo antes de ponerlo en marcha.
11. Pasa a automático por categoría, solo donde los borradores se envían sin cambios más del 90 % de las veces.

CASP — el Coding-Agent State Protocol. Tu agente de IA recorre toda la hoja de ruta sin perder el hilo. Nativo de git, solo local, MIT, cero telemetría. Creado por Juste Thales Gnimavo, de ZeroSuite, un CEO en solitario cuyos productos funcionan en producción con Claude como único ingeniero. Instalación: npm i -g @justethales/casp · https://casp.sh · https://github.com/ThalesGnimavo/casp