20 de julio de 2026 # Cómo hacer que una empresa aprenda con la IA  *Usar IA permite hacer más trabajo. Conseguir que lo aprendido en una tarea mejore la siguiente exige bastante más que abrir otro chat.* Alguien de tu empresa dedica dos horas a preparar con IA una propuesta para un cliente. Durante ese tiempo aporta contexto, corrige el tono, descarta dos fuentes antiguas, aclara una excepción en los precios y termina definiendo cómo se comprueba que la propuesta está bien. Al final envía un buen documento, pero casi todo lo aprendido durante esas dos horas se queda dentro de la conversación. Una semana después, otra persona recibe un encargo parecido, y puede encontrar la propuesta final, pero no sabe qué fuentes resultaron útiles, qué errores hubo que corregir ni por qué se tomó cada decisión, con lo cual abre un chat nuevo y empieza otra vez. Este problema ya existía antes de la IA. Buena parte del conocimiento de una empresa siempre ha estado repartido entre correos, documentos y la cabeza de las personas. La IA lo hace más visible porque ahora una sola conversación puede concentrar mucho razonamiento, muchas correcciones y varias decisiones valiosas. Si ese trabajo no se captura, la empresa conserva el resultado, pero pierde casi todo el proceso que permitió obtenerlo. Puedes dar herramientas muy capaces a toda la plantilla y conseguir que produzcan más, y eso no garantiza que la organización aprenda. Para que ocurra, el trabajo de hoy tiene que dejar algo útil para el de mañana. ## El aprendizaje se pierde al cerrar el chat  La forma más común de medir la adopción de la IA sigue siendo contar licencias, usuarios activos, consultas o tiempo ahorrado (la métrica del tiempo ahorrado me molesta especialmente). Son datos útiles, pero dicen poco sobre cuánto conocimiento nuevo conserva la empresa o la cantidad de inteligencia aportada a los procesos. Una conversación puede ahorrar tres horas y desaparecer sin dejar más rastro que el documento final. También puede descubrir una forma mejor de hacer una tarea, identificar una fuente fiable o encontrar un error que nadie debería volver a cometer. Nada de eso queda disponible para el resto de la organización si permanece enterrado en el historial de una persona. Con los agentes aparece una posibilidad nueva. Un agente puede recibir un objetivo, usar herramientas, comprobar su avance y seguir trabajando hasta alcanzar un resultado. Esa repetición se suele llamar bucle. Ya he explicado con detalle [[86-Loop-engineering-vs-prompt-engineering|cómo funcionan estos bucles]] y [[81-El-harness-y-simular-agentes|qué papel tiene el harness]], así que aquí basta con una idea sencilla: el usuario ya no tiene que dirigir cada paso. El bucle puede mejorar el resultado de una tarea concreta. Para que también mejore la siguiente, las correcciones y decisiones descubiertas durante su ejecución tienen que guardarse en algún sitio que otro agente pueda utilizar. Yo lo veo con mis propios agentes. Si corrijo un resultado, obtengo un documento mejor; si incorporo esa corrección a las instrucciones del agente, mejoran también todos los trabajos que vengan después, y esa es la diferencia entre arreglar una cosa y arreglar la forma de hacerla. Lo segundo cuesta unos minutos más, pero evita que el mismo error vuelva a mi mesa. ## Convertir una buena ejecución en una habilidad  Cuando un proceso funciona, lo puedes escribir con suficiente detalle para que un agente vuelva a ejecutarlo. En los sistemas de agentes, ese conjunto de instrucciones suele llamarse habilidad o *skill*. Yo lo suelo guardar en ficheros de texto con instrucciones detalladas y lo llamo *directiva*. Una habilidad explica qué resultado se busca, qué información necesita el agente, qué fuentes debe consultar, qué herramientas puede usar, qué pasos suelen funcionar y cómo se comprueba la calidad. También incluye las excepciones conocidas y los casos en los que debe pedir ayuda a una persona. Vuelve a la propuesta comercial del principio. La habilidad podría indicar que el agente debe recuperar la versión vigente del contrato, consultar la tarifa actual, revisar las últimas conversaciones con el cliente y comprobar que todas las afirmaciones importantes tienen una fuente. Si el margen baja de cierto nivel o aparece una condición fuera de catálogo, la propuesta pasa a revisión humana. Ese fichero no hace el trabajo por sí solo. El agente lo carga cuando recibe una tarea de ese tipo y lo utiliza como procedimiento. Si durante una ejecución alguien detecta una fuente antigua, una excepción nueva o una comprobación que falta, se actualiza el procedimiento para los siguientes casos. Garry Tan, presidente de Y Combinator, lleva esta idea bastante lejos. [En una charla reciente](https://www.youtube.com/watch?v=eBUyTS7SzV4) comparó cada habilidad con un empleado y contó que su producción de código se había multiplicado por 400 desde que empezó a trabajar con agentes. Yo creo que ninguna de las dos afirmaciones hay que llevarla al pie de la letra. Un fichero carece de experiencia propia, responsabilidad y conocimiento adquirido durante años de trabajo. Se parece más a un procedimiento que un agente sabe ejecutar. Y la cifra de 400 compara líneas de código escritas por la misma persona en dos momentos muy distintos, así que sirve para entender el tamaño del cambio que Tan percibe en su trabajo, pero no para calcular la productividad de una empresa ni la de nadie. La parte útil de su propuesta no depende de esa cifra. Cuando una tarea se repite, conservar el método evita reconstruirlo en cada ocasión. Además, permite que las correcciones de una persona terminen beneficiando a otras. Un procedimiento compartido amplía también el alcance de sus errores. Si la forma de trabajar es deficiente, convertirla en una habilidad hará que el fallo se repita con más facilidad. Antes de reutilizarla conviene comprobar que merece la pena y dejar claro quién responde de mantenerla. ## Una memoria útil necesita mantenimiento  Una habilidad no puede trabajar solo con instrucciones. También necesita información sobre la empresa, el cliente y el caso concreto. Correos, reuniones, contratos, decisiones, incidencias, informes y conversaciones con clientes forman parte de la memoria organizativa. Hasta ahora accedíamos a ella preguntando a alguien, buscando en carpetas o recordando dónde habíamos visto un documento. Un agente puede buscar en grandes cantidades de información, pero sigue necesitando que alguien decida qué fuentes son válidas y cuáles están vigentes. Pon que encuentra dos precios para el mismo producto. Uno aparece en una presentación del año pasado y otro en la tarifa actual. Una búsqueda puede devolver ambos documentos. El agente necesita saber cuál manda, cuándo entró en vigor, quién lo aprobó y si existen excepciones para ese cliente. Guardar más información no resuelve este problema. Cada dato importante debería conservar su procedencia, es decir, de dónde salió, y además fecha, responsable y alguna indicación sobre si sigue vigente. Cuando una decisión nueva contradice a otra anterior, el sistema debe detectar el conflicto o dejar de usar la versión antigua. Esto exige mantenimiento. Hay que retirar información que ya no vale, resolver contradicciones y revisar los procedimientos cada vez que cambian las reglas, que es de esas tareas que nunca aparecen en el plan y que aun así sostienen todo lo demás. De lo contrario, la empresa puede acabar recuperando datos antiguos con mucha seguridad y utilizándolos dentro de procesos que se ejecutan una y otra vez. Garry Tan llama a esta combinación de información y selección un “cerebro de empresa”. El nombre puede sonar ambicioso, pero la función es bastante concreta: ante cada tarea, localizar una cantidad manejable de información relevante y entregársela al agente. La calidad depende menos de cuánto se haya guardado que de lo bien cuidado que esté aquello que se recupera. ## Poner nombre a las cosas y a sus relaciones  Una memoria bien mantenida devuelve hechos y documentos. El agente necesita además conocer las relaciones que existen entre los datos del negocio. Coge una reclamación cualquiera. El agente puede localizar el correo del cliente, la factura, el manual del producto y las condiciones del servicio. Para resolver el caso también necesita saber que la reclamación afecta a un pedido concreto, que ese pedido contiene un producto, que el producto tiene una garantía y que el cliente dispone de un contrato con un plazo de respuesta determinado. Esas relaciones se pueden escribir de una forma muy sencilla: ```text Cliente -> hizo -> Pedido Pedido -> contiene -> Producto Producto -> está cubierto por -> Garantía Cliente -> tiene -> Contrato de servicio ``` El nombre técnico de esta forma de organizar el conocimiento es *ontología*. El término parece más complicado que la idea. Una ontología establece qué tipos de cosas existen en un negocio, qué propiedades tiene cada una, cómo se relacionan y las reglas y acciones a ejecutar según qué condiciones ocurren. Un cliente, un pedido, un producto y una incidencia serían tipos de entidades. “Hizo”, “contiene” o “está cubierto por” serían relaciones. A partir de ese vocabulario común, distintos sistemas y agentes pueden referirse a las mismas cosas de una manera coherente. Microsoft ha publicado un proyecto llamado [Ontology Playground](https://github.com/microsoft/Ontology-Playground) que permite diseñar y explorar estas relaciones de forma visual. La herramienta no es el asunto principal (y es bastante *techie*, no es para todo el mundo). Su interés está en mostrar que una ontología puede dejar de ser un documento técnico difícil de leer y convertirse en una representación comprensible del negocio. >  > *Ontology Playground, de Microsoft* Los documentos siguen aportando los detalles, las explicaciones y el contexto. La ontología ayuda a conectarlos con clientes, productos, procesos y decisiones concretas. Gracias a esas relaciones, un agente puede combinar información que está repartida entre varios sistemas aunque los documentos no utilicen exactamente las mismas palabras. Esta estructura también necesita revisión. Si la empresa define mal una relación o deja desactualizada una regla, el agente puede aplicar ese error a muchos casos. Organizar el conocimiento permite utilizarlo mejor, pero también aumenta el alcance de cualquier dato incorrecto. ## Un agente que actúa necesita límites  Un agente que dispone de un procedimiento, información de la empresa y relaciones entre los datos ya puede hacer bastante. Si además actúa sobre el correo, el CRM, la facturación o los documentos compartidos, necesita controles claros. Responsables de producto e ingeniería de Anthropic señalan tres elementos especialmente importantes: identidad, permisos y evaluación. La identidad permite saber qué agente ha realizado cada acción. En lugar de usar una cuenta compartida o las credenciales completas de un empleado, el agente dispone de una identidad propia. Así se puede consultar qué leyó, qué modificó, cuándo lo hizo y bajo qué autoridad. Los permisos determinan hasta dónde puede llegar. Un agente de atención al cliente puede necesitar acceso a pedidos, contratos e incidencias. Quizá pueda aprobar una devolución hasta cierto importe. Eso no le da derecho a cambiar la tarifa general, consultar información de recursos humanos o borrar el historial del cliente. Conviene asignar los accesos según el resultado que debe conseguir y retirarlos cuando dejan de ser necesarios. Si el encargo cambia y necesita un permiso nuevo, lo solicita. Una persona o una política de la empresa decide si se concede. La evaluación comprueba si el agente está haciendo bien su trabajo. En este sector se utiliza mucho la palabra *eval*, abreviatura de *evaluation*. Una eval es simplemente una prueba con criterios observables. En el caso de la propuesta comercial, las pruebas podrían comprobar que se usó la tarifa vigente, que aparecen todas las cláusulas obligatorias, que ninguna afirmación carece de respaldo y que los casos de cierto importe pasan por una persona. También puede haber ejemplos preparados de antemano para comprobar que una nueva versión de la habilidad no estropea algo que antes funcionaba. Terminar todos los pasos no garantiza que el resultado sea correcto. La evaluación debe mirar el resultado, los datos utilizados y las decisiones tomadas. Si solo medimos cuánto tarda el agente, podemos premiar un proceso rápido que produce más errores o genera trabajo de revisión. Anthropic propone medir de forma gradual. Primero se observa si una persona trabaja mejor con el agente, teniendo en cuenta tiempo, calidad y correcciones. Después se analiza el equipo. Solo cuando esa forma de trabajo funciona tiene sentido conectar procesos de varios departamentos. Empezar por una tarea individual ayuda a evitar el despliegue de muchos agentes a la vez, cada uno produciendo resultados por su cuenta y sin una dirección común que los ordene. Crear diez prototipos puede resultar barato; mantenerlos, darles acceso a datos y resolver sus contradicciones ya no lo es, y me da la sensación de que ahí es donde se atasca casi todo el mundo. Contar agentes dice muy poco sobre la capacidad de una empresa. Hay que revisar el conjunto formado por el procedimiento, la memoria, el conocimiento organizado, los permisos y las pruebas. Un modelo muy capaz puede usar una tarifa antigua, ejecutar un procedimiento deficiente o acceder a información que no necesita si cualquiera de esas piezas falla. ## Cómo empezar con una tarea real  Garry Tan recomienda no hacer nunca un trabajo de una sola vez: si una tarea sale bien, hay que convertirla en una habilidad. Como disciplina me parece buena. Aplicada al pie de la letra, puede producir un montón de procedimientos que luego no mantiene nadie. Hay tareas que de verdad ocurren una sola vez. También hay trabajos tan variables que documentarlos cuesta más que repetirlos. Intentar capturarlo todo llenaría la memoria de instrucciones poco usadas y versiones antiguas. Yo empezaría por una tarea que se repita, consuma tiempo y tenga un resultado que podamos juzgar. Preparar propuestas, revisar facturas, responder ciertas incidencias, redactar el informe semanal de un proyecto o comprobar documentación son buenos candidatos. Después de una ejecución satisfactoria, dedicaría unos minutos a guardar cinco grupos de información: - **El encargo y el resultado.** Qué información entra, qué debe producir el agente y qué condiciones debe cumplir el resultado para considerarlo válido. - **La forma de hacerlo.** Qué pasos siguió, qué herramientas utilizó y qué fuentes debe consultar. Si una fuente tiene versiones, se indica cuál está vigente y quién la mantiene. - **Lo aprendido durante la ejecución.** Qué errores aparecieron, qué fuentes se descartaron, qué correcciones mejoraron el resultado, qué excepciones surgieron y qué decisiones tuvo que tomar una persona. - **Los límites.** Con qué identidad trabaja el agente, qué permisos necesita y en qué casos debe detenerse, pedir aprobación o entregar el caso a alguien. - **El mantenimiento.** Quién responde del procedimiento, cuándo se revisará y qué pruebas tendrá que superar cada nueva versión. Con esa información se prepara una primera habilidad y se prueba con un caso nuevo. Entonces se comparan el tiempo empleado, la calidad del resultado y la cantidad de correcciones necesarias. Si solo funciona con el ejemplo original, todavía no tenemos un procedimiento reutilizable. Las siguientes ejecuciones sirven para mejorarlo: una excepción que sale a menudo se incorpora a las instrucciones, una fuente que ha quedado antigua se sustituye y una prueba que no detectó un error se corrige. No todas las observaciones deben convertirse en una regla general, así que alguien tiene que decidir cuáles se añaden y cuáles pertenecen solo a un caso concreto. Para una primera prueba, elegiría una sola tarea, nombraría a una persona responsable y prepararía varios casos, incluidos uno o dos que hayan dado problemas antes. Después de cada ejecución, revisaría qué información faltó, qué corrección hubo que repetir y qué parte del procedimiento conviene cambiar. Con tres o cuatro casos ya debería verse si la habilidad reduce el trabajo de revisión o si solo ha trasladado las explicaciones del chat a un fichero. > [!tip]+ Para profundizar en Internet > - [Cómo trabajan las empresas con agentes](https://www.youtube.com/watch?v=eBUyTS7SzV4) · Garry Tan (Y Combinator) - De aquí salen la idea de convertir cada buen trabajo en una habilidad y la cifra del 400. > - [Identidad, permisos y evaluación en agentes](https://www.youtube.com/watch?v=ksfm6jeTg3Q) · Anthropic - La conversación de producto e ingeniería en la que se apoya la sección de los límites. > - [Ontology Playground](https://github.com/microsoft/Ontology-Playground) · Microsoft - El proyecto para diseñar y explorar las relaciones del negocio de forma visual. > - [Bucles y programas para agentes](https://x.com/sairahul1/status/2078367561453101097) · Sai Rahul - El hilo que explica el bucle en corto, por si quieres el detalle técnico. > [!tip]+ En esta web > - [[93-maquina-de-escalar-colinas|La máquina de escalar colinas]] - El mismo bucle visto desde fuera: por qué la ventaja se ha mudado del modelo al sistema que lo entrena. > - [[86-Loop-engineering-vs-prompt-engineering|Loop engineering vs prompt engineering]] - Cómo funciona el bucle de un agente, con detalle. > - [[81-El-harness-y-simular-agentes|El harness, la capa que rodea al modelo]] - Qué piezas acompañan al modelo cuando trabaja. --- Publicado el 20 de julio de 2026