Cómo ADRI aprende de su propio trabajo y abre tickets por su cuenta

Una IA que trabaja todos los días se equivoca todos los días. Lo útil es qué pasa después: si el error se repite o si alguien lo detecta y lo corrige. En ADRI hay dos mecanismos para eso, y funcionan sin que nadie tenga que acordarse.

Te contamos cómo funcionan, qué ves tú como cliente y qué frenos tienen.

Las cuatro formas en que ADRI aprende

ADRI no reentrena ningún modelo con tus datos. Guarda, ordena y reutiliza lo que pasa en su trabajo diario, de cuatro formas distintas.

• Lo que aprende de ti. Al terminar una conversación, un modelo pequeño y rápido repasa el intercambio y actualiza tu perfil: cómo prefieres que te escriba, qué firma usas, qué correcciones le has hecho. Ese perfil sirve para el tono y las preferencias. No sirve como fuente de datos: si necesita un correo o el estado de una cuenta, ADRI lo consulta en la plataforma en lugar de sacarlo de memoria.
• Su memoria de conversaciones. Tus chats anteriores y los archivos que generó para ti se indexan cada pocos minutos. Así entiende «lo que miramos de la competencia» aunque aquel chat dijera «estudio de rivales». Cada usuario solo busca en lo suyo. Si la búsqueda por significado falla, cae a la búsqueda por palabras en lugar de dar error.
• Lecciones técnicas. Cuando una herramienta falla y ADRI encuentra cómo resolverlo, o cuando se atasca en un bucle, o cuando tú le corriges, puede guardar una lección corta del tipo «para este caso, haz esto otro». Más abajo explicamos por qué una lección nueva no vale nada hasta que se demuestra.
• Experiencia por herramienta. El navegador, por ejemplo, recuerda qué funciona en cada web y olvida los apuntes viejos.

La regla que lo une todo es sencilla: almacenar mucho, inyectar poco. La memoria guardada puede crecer, pero a cada conversación solo llega un trozo pequeño y relevante. Así no se encarece cada respuesta. Lo explicamos con más detalle en cómo funciona la búsqueda semántica en la base de conocimiento.

La revisión de cada madrugada

Aprender en caliente acumula duplicados y apuntes que ya no aplican. Cada madrugada corre una revisión que pone orden:

1. Limpia los perfiles de usuario. Quita duplicados, resuelve contradicciones (gana lo más reciente) y poda.
2. Repasa el ciclo de vida de las lecciones. Promueve las que han demostrado funcionar, retira las que fallan más de lo que aciertan y funde las que dicen lo mismo con otras palabras.
3. Retira lecciones que ya no tienen sentido. Si habla de una herramienta que su agente ya no tiene, el código la retira. Es una comprobación mecánica, no la opinión de un modelo, y es reversible.
4. Hace copia de las tablas de aprendizaje. Una copia local diaria, aparte de las copias de seguridad generales.
5. Guarda las métricas de la noche. Así se ve la tendencia en lugar de fiarse de la intuición.

Hay un paso más que hoy está en modo prueba: un modelo compara cada lección con las instrucciones vigentes del agente y propone retirar las que ya están cubiertas o las que las contradicen. De momento solo propone y lo deja apuntado; no toca nada hasta que lo revisemos. Y aunque se active, solo puede retirar una lección si cita literalmente la parte de las instrucciones que la cubre, y nunca más de un tercio de las lecciones de un agente en una noche.

Cómo evitamos que aprender estropee algo

Un sistema que aprende solo puede aprender mentiras: si guarda como éxito algo que salió mal, lo repetirá con más confianza. Por eso casi todo el trabajo está en los frenos:

• Una lección empieza como candidata. Solo pasa a verificada tras varios usos con éxito y sin fallos. Si falla más de lo que acierta, se retira. Si deja de usarse durante semanas, también. Si el error que corregía vuelve a aparecer, la lección revive.
• Solo cobra mérito si se usó de verdad. Una lección sobre una herramienta solo suma un éxito si en esa tarea se usó esa herramienta. Una tarea cancelada o cortada a medias no cuenta ni como éxito ni como fallo.
• Datos personales fuera. Las lecciones técnicas son comunes a toda la instalación, así que se limpian de datos personales dos veces antes de guardarse.
• Las lecciones no tocan las instrucciones fijas. Se añaden como nota al principio de la petición, como mucho las tres más parecidas al caso. Si algo va mal, se apagan con un interruptor.
• Tu perfil no se puede encoger por error. Si al actualizarlo el resultado sale mucho más corto que el original, se descarta el cambio. Antes de reescribirlo se guarda una copia.
• Las pruebas no pagan aprendizaje. Nuestras baterías de pruebas tienen un candado que impide que disparen llamadas de aprendizaje reales y facturables.
• Puedes borrarlo. Los roles con permiso pueden borrar de golpe la memoria de ADRI. Por defecto lo tienen super-admin, admin y manager.

Es la misma filosofía que contamos en los arneses que deciden qué modelo trabaja y quién revisa: el modelo propone; el código comprueba.

El vigilante: un agente que lee los registros

El segundo mecanismo no aprende: vigila. Es un agente aparte, el vigilante, que corre en cada servidor una vez al día, a una hora aleatoria de la noche. Lee lo que se ha escrito en los registros de ADRI y de la plataforma desde la última vez, agrupa los errores por tipo y, si encuentra un incidente real, abre un ticket en nuestra instalación central de soporte.

Los pasos 2 y 4 salieron de errores reales. En julio de 2026 revisamos los seis tickets que el vigilante había abierto en dos días: tres citaban contadores y nombres que no existían en ningún registro. El modelo había inventado incidentes verosímiles. No le pedimos honradez: le obligamos a citar líneas que la herramienta puede buscar. Ese mismo mes, un solo fallo en un recurso compartido abrió siete tickets idénticos, uno por servidor. Desde entonces cuenta como uno.

¿Y si el vigilante deja de pasar? Hay un segundo aviso: cada mañana se comprueba cuándo fue su última revisión correcta. Si han pasado más de 30 horas, se abre un ticket avisando de ello. Y si se cuelga o repite la misma acción en bucle, se le corta.

Qué ves tú como cliente

En el día a día, nada. Los tickets del vigilante llegan a nuestro equipo de soporte, no a tu bandeja. La idea es que nos enteremos de un fallo por el registro, a menudo antes de que te afecte. No siempre llegaremos antes: el vigilante revisa una vez al día y algunos fallos solo se notan cuando alguien usa la función.

Lo que sí notas es el efecto del aprendizaje: ADRI te escribe con tu tono, recuerda lo que ya hablasteis y deja de repetir algunos tropiezos técnicos. Si quieres que tus propios servidores abran tickets con la misma lógica de huellas, la plataforma tiene una API: la tienes en tickets y soporte con IA.

Lo que todavía no hace

• No se repara solo. El vigilante funciona en modo solo lectura. Existe una segunda fase pensada para cerrar tickets tras arreglar el fallo, pero está apagada y la reparación automática no tiene hoy ningún camino real. Quien arregla es una persona.
• No es infalible. Un ticket del vigilante es una hipótesis con evidencia, no un hecho. Lo revisamos antes de actuar.
• Aprender no es entender. Una lección verificada ha funcionado varias veces; no garantiza el siguiente caso.
• Mide, y a veces la medición también falla. En septiembre auditamos el propio ciclo nocturno y encontramos que daba la noche por buena aunque fallara algún paso. Lo corregimos.

Si quieres ver la lista de agentes y qué hace cada uno, está en qué hace ADRI. Para probarlo, empieza por el chat con ADRI. Y si te interesa cómo tratamos los datos que aprende, lo tienes en seguridad y cumplimiento.

• ADRI
• Autoaprendizaje
• Tickets automáticos
• Monitorización