Imagina un comercio chico que atiende reclamos por mensaje. Un asistente de IA lee cada conversación y propone qué hacer. Una tarde propone devolverle el dinero a una clienta por un pedido. La propuesta suena razonable, está bien redactada y viene con una explicación amable. Hay un detalle: ese pedido ya se había reembolsado la semana anterior.

El caso es inventado, pero el tipo de error es real. En una charla de la conferencia AI Engineer, Frank Coyle, de la Universidad de California en Berkeley, usó tres ejemplos así: un segundo reembolso sobre la misma orden, un pago enviado a quien atiende en lugar de a quien compró, y un estado inventado, como «probablemente enviado», cuando los únicos permitidos son pagado, enviado o reembolsado [C8]. Ninguno de los tres es absurdo. Los tres parecen correctos hasta que alguien que conoce el negocio los mira dos veces.

Esta guía trata de lo que haces antes de pedirle algo a una IA para que esos errores no pasen sin que nadie los vea. No hace falta una herramienta nueva ni saber programar. Hace falta escribir, en una hoja, el mapa de tu trabajo con sus reglas. A ese mapa los especialistas lo llaman ontología. La palabra asusta más que la idea, y vamos a ver de dónde viene.

Por qué la IA propone cosas que suenan bien y están mal

Ilustración: dos monedas lisas idénticas, de canto grueso y estriado, apoyadas y apenas superpuestas sobre un fondo cálido y vacío; la primera es de color arena y la segunda, terracota.
Dos piezas idénticas: el segundo reembolso. · Ilustración generada con IA

Un modelo de lenguaje no consulta una base de hechos: produce la respuesta más plausible a partir de lo que aprendió. Eso lo hace muy útil para redactar, resumir y ordenar. También significa que puede dar algo verosímil y falso con la misma seguridad con que da algo cierto.

Hay investigación que lo sostiene desde dos ángulos. Un trabajo de investigación argumenta, con teoría del aprendizaje, que es imposible eliminar por completo las respuestas inventadas en estos modelos [C1]. Otro trabajo, de investigadores de OpenAI y del Georgia Tech, propone que persisten en parte porque el entrenamiento y la evaluación premian adivinar con seguridad por encima de admitir que no se sabe [C1]. Son argumentos generales: no miden tu caso ni el de ninguna herramienta concreta.

De ahí sale la tesis de esta guía, y es una tesis modesta: alucinar no se arregla, se acota. No esperes que el próximo modelo deje de equivocarse. Lo que sí puedes hacer es poner reglas tuyas alrededor de lo que el modelo propone, para que ciertos errores, los que ya sabes que son graves en tu trabajo, no lleguen a ejecutarse.

Qué es una ontología, sin la palabra rara

Una ontología es el mapa escrito de tu trabajo: qué cosas hay, cómo se conectan, qué se puede hacer con ellas y quién decide. Nada más.

La pregunta de fondo es muy antigua. Aristóteles propuso una «filosofía primera» que estudia lo que es, en tanto que es: qué existe y de qué tipos [C12]. Los griegos hablaban del ser, pero no usaban la palabra «ontología»; esa aparece mucho después, en el siglo XVII, en textos de filósofos europeos [C12].

La informática la tomó prestada por una razón práctica. A comienzos de los años noventa, un estudio financiado por el Departamento de Defensa de Estados Unidos se preguntó cómo hacer que sistemas distintos compartieran conocimiento sin malentenderse. En 1993, Tom Gruber definió el término para ese uso: la especificación de un vocabulario de un dominio compartido, con sus clases, relaciones y funciones [C13]. Dicho en llano: ponerse de acuerdo, por escrito, sobre qué significan las palabras del negocio.

Más recientemente, empresas de software llevaron esa idea al trabajo diario de las organizaciones. Palantir, que vende una plataforma de datos, describe su «Ontology» como una capa que conecta los datos con sus equivalentes del mundo real, desde equipos y productos hasta pedidos y transacciones, e incluye no solo el significado (objetos, propiedades, vínculos) sino también lo que se puede hacer (acciones, reglas, seguridad) [C2] [C14]. Conviene leerlo con su contexto: es la definición de un proveedor para su producto, no un estándar universal, y no necesitas ninguna de esas plataformas para aplicar la idea.

Lo que te sirve de todo ese recorrido es la parte práctica. Un buen mapa de trabajo tiene cinco piezas.

Línea de tiempo de cuatro paradas. Aristóteles: una «filosofía primera» sobre lo que es, en tanto que es; los griegos no usaban la palabra ontología. Siglo XVII: la palabra aparece en textos de filósofos europeos, según fuentes secundarias. Años noventa: un estudio financiado por el Departamento de Defensa de Estados Unidos se pregunta cómo hacer que sistemas distintos compartan conocimiento; en 1993 Tom Gruber define el término para ese uso. Después: empresas como Palantir llevan la idea al trabajo diario de las organizaciones, sin fecha de introducción verificada.
De Aristóteles a las plataformas de datos [C12] [C13] [C14]

Las cinco piezas del mapa

En el lenguaje de los especialistas En tu trabajo
Objeto una cosa concreta: esta clienta, este pedido
Tipo de objeto la clase de cosa: Cliente, Pedido, Reembolso
Relación cómo se conectan: este pedido pertenece a esta clienta
Acción un verbo permitido, con sus datos y sus consecuencias: reembolsar, asignar, aprobar
Regla de revisión la condición que tiene que cumplirse antes de que el verbo se ejecute

1. Las cosas. Empieza por nombrar los tipos de cosa que mueven tu trabajo. En la documentación de Palantir, un tipo de objeto es la definición de una entidad o evento del mundo real, como «Empleado» o «Vuelo», y un objeto es un caso concreto, como una persona o un vuelo determinado [C3]. Tú no necesitas el vocabulario técnico: necesitas decidir qué cosas existen en tu trabajo y ponerles un nombre que todos entiendan igual.

2. Las conexiones. Un pedido pertenece a una clienta. Un reembolso pertenece a un pedido. Escribir las conexiones obliga a decidir cosas que solemos dar por obvias, como si un pedido puede tener más de un reembolso.

3. Los verbos. Un verbo no es cualquier cambio: es un cambio que tu negocio reconoce, con sus datos y sus consecuencias. La documentación de Palantir describe una «acción» como un cambio definido de antemano; su ejemplo es «Asignar empleado», que cambia el rol de una persona, avisa a su jefe anterior y al nuevo, y comprueba que quien lo hace sea alguien autorizado de Recursos Humanos [C4]. Fíjate en lo que hace ese ejemplo: junta en un solo lugar qué cambia, a quién se avisa y quién puede hacerlo.

4. Quién puede hacer qué. Un verbo sin dueño es una invitación al desorden. El ejemplo oficial de Palantir lo muestra bien: cambiar el avión asignado a un vuelo solo puede hacerlo un controlador de vuelos, y solo con aviones que sigan en operación; la acción no se puede enviar si esas condiciones no se cumplen [C5]. Es la misma lógica de tu comercio, en otro rubro: no basta con que la acción exista, hay que decir quién la puede usar y bajo qué condiciones.

5. La revisión antes de ejecutar. Esta es la pieza que convierte un mapa en una baranda. Antes de que el verbo se ejecute, se comprueba que se cumplan las reglas. Si no se cumplen, la propuesta vuelve atrás o la mira una persona. Coyle lo resume así: el agente no modifica nada hasta que su resultado pasa la validación; primero se revisa que el pedido tenga la forma correcta y después que tenga sentido para el negocio [C8].

El ejemplo completo: el comercio de reembolsos

Este ejemplo es hipotético: lo armamos para entender la idea, no describe a ningún comercio real.

Las cosas: Cliente, Pedido, Reembolso.

Las conexiones: un pedido pertenece a un cliente; un reembolso pertenece a un pedido.

El verbo: Reembolsar.

Quién decide: la persona responsable de atención aprueba; el asistente solo propone.

Las tres reglas de revisión:

  1. Un pedido tiene como máximo un reembolso.
  2. El dinero va al cliente dueño del pedido, nunca a la persona que atiende.
  3. El estado del pedido solo puede ser pagado, enviado o reembolsado.

Con ese mapa escrito, el asistente trabaja así. Lee la conversación y propone: «Reembolsar el pedido 1042 a la clienta Martínez». Antes de ejecutar nada, se revisan las tres reglas contra lo que hay anotado.

Lo que propone el asistente Qué regla lo frena Qué pasa
Reembolsar un pedido que ya tiene un reembolso Regla 1 Vuelve atrás; se avisa que ya fue reembolsado
Enviar el dinero a quien atiende el reclamo Regla 2 Vuelve atrás; lo revisa una persona
Marcar el pedido como «probablemente enviado» Regla 3 Se rechaza; solo se admiten los tres estados

Mira lo que cambió. El asistente sigue pudiendo equivocarse, y nadie le pidió que dejara de hacerlo. Lo que cambió es que sus errores más graves, los que tu negocio no puede permitirse, ya no se ejecutan solos. La IA propone; tus reglas deciden qué pasa.

Una aclaración honesta sobre las reglas: no funcionan solas por existir. Funcionan porque alguien las escribió con claridad y porque se comprueban antes de ejecutar. En los lenguajes formales que usan los especialistas, una regla como «solo puede haber uno» no rechaza por sí misma un segundo valor: puede concluir que se trata de la misma cosa con otro nombre, salvo que alguien declare que son distintas [C8]. Para ti la lección práctica es sencilla: escribe la regla de forma que se pueda comprobar con los datos que realmente tienes.

Mapa del comercio de reembolsos, ejemplo hipotético. Tres cajas conectadas: Cliente, Pedido y Reembolso; un pedido pertenece a un cliente y un reembolso pertenece a un pedido. Sobre Reembolso, el verbo «Reembolsar»: la persona responsable de atención aprueba, el asistente solo propone. Debajo, las tres reglas de revisión: un pedido tiene como máximo un reembolso; el dinero va al cliente dueño del pedido; el estado del pedido solo puede ser pagado, enviado o reembolsado.
El mapa del comercio de reembolsos (ejemplo hipotético)

El ejercicio: tu trabajo en una hoja

Necesitas una hoja, un lápiz y un rato tranquilo. No abras ninguna herramienta de IA mientras lo haces.

Paso 0: elige un trabajo. Que lo hagas con frecuencia, que lo conozcas bien, que puedas reconocer si el resultado salió bien o mal, y que un error no afecte de forma grave a una persona, a dinero ni a la seguridad. No uses datos personales ni sensibles de nadie en la hoja.

Paso 1: lista las cosas. Escribe los tipos de cosa que aparecen en ese trabajo, tres a cinco para empezar. Si te salen más de ocho, probablemente estés mezclando dos trabajos.

Paso 2: dibuja las conexiones. Entre cada par de cosas relacionadas, una línea con una frase corta: «pertenece a», «se genera a partir de». Fíjate en las conexiones que no sabes responder; ahí suele esconderse el problema.

Paso 3: lista los verbos. ¿Qué cambios se hacen en ese trabajo? Aprobar, enviar, corregir, cerrar. Al lado de cada uno, escribe quién puede hacerlo.

Paso 4: escribe tres reglas que nunca deben romperse. Una regla útil es una frase que alguien pueda comprobar sin interpretarla. «Los reembolsos deben ser razonables» no sirve. «Un pedido tiene como máximo un reembolso» sí. Piensa en los tres errores más caros que recuerdes y conviértelos en reglas.

Paso 5: decide qué se revisa antes de ejecutar. Para cada verbo, anota quién o qué comprueba las reglas antes de que se haga. Puede ser una persona, una lista de verificación o una regla en una planilla. Lo importante es que la revisión exista y que ocurra antes, no después.

Al terminar tienes una hoja con cosas, conexiones, verbos, dueños y tres reglas revisables. Esa hoja ya es útil, aunque nunca uses una IA: es una descripción de tu trabajo que otra persona podría leer y entender. Si después decides usar una, esa hoja es lo primero que le das.

Errores comunes al armar el mapa

Quienes han documentado estos mapas en organizaciones grandes señalan fallas que se repiten y que vale la pena evitar, aunque tu mapa sea de una hoja. La charla de gobernanza de Palantir, que es un contenido de proveedor y no una evaluación independiente, las nombra con humor: el «objeto dios», que mezcla varias cosas en una sola; el «cajón de sastre», que copia todas las columnas de una planilla sin decidir cuáles importan; los «silos», donde cada área tiene su propia versión del mismo cliente; y una acción distinta por cada dato que cambia [C7]. Si tu hoja se parece a alguno de esos, simplifica antes de seguir.

Lo que este mapa no resuelve

No arregla datos desordenados. Si dos de tus planillas discrepan sobre quién es la misma clienta, el mapa no lo resuelve: puede propagar el error con una apariencia más ordenada. Francisco Ferreira, ex-Palantir y fundador de Datalinks, una empresa del rubro, insiste en empezar por un trabajo concreto que valga la pena y por datos en los que se pueda confiar [C6]. Es una fuente con interés comercial, pero la advertencia es de sentido común.

No decide quién manda. Un mapa necesita un responsable de cada concepto: quién responde por lo que significa «cliente» en tu negocio y quién autoriza cambiar una regla. Las plataformas que usan estos mapas en serio separan los permisos sobre las definiciones, como qué tipos de cosa y de acción existen, de los permisos sobre los casos concretos, es decir, los datos mismos [C9]. En una hoja, el equivalente es sencillo: anota quién puede cambiar las reglas y quién puede ejecutar los verbos, y que no sean siempre la misma persona.

No siempre conviene hacerlo. Si no puedes señalar una decisión o una acción real, quién es su dueño, de dónde sale el dato y qué error quieres evitar, lo más útil es mejorar primero tus datos y tus procesos [C10]. Un mapa elaborado sobre un trabajo que todavía no entiendes bien solo ordena la confusión.

No tiene resultados medidos. Ninguna de las fuentes que revisamos publica cifras de que escribir un mapa así mejore resultados en la práctica: la charla de Coyle muestra ejemplos conceptuales sin una implementación completa, la de Ferreira no publica pruebas reproducibles y la de la empresa Neo4j, otra vendedora de software del rubro, no presenta resultados medidos [C11]. Lo que te ofrece esta guía es un método para pensar tu trabajo con más claridad. No te promete un número.

Mantener, ajustar o retirar

Después de usar tu hoja durante unas semanas con un trabajo real, decide qué hacer con ella.

  • Mantenla si las tres reglas atajaron al menos un error que, de otro modo, habría pasado, o si la hoja le permitió a otra persona entender el trabajo sin que tú se lo explicaras.
  • Ajústala si alguna regla resultó imposible de comprobar con los datos que tienes, si apareció una cosa que no estaba en el mapa, o si descubriste que dos personas entendían de forma distinta una misma palabra. Esas diferencias son justo lo que el mapa debía sacar a la luz.
  • Retírala si el trabajo cambió tanto que la hoja ya no lo describe, o si ninguna regla atajó nada y el trabajo es tan simple que el mapa solo agrega trámite. Escribir el mapa te habrá servido de todos modos para entender mejor ese trabajo.

La próxima vez que una herramienta te proponga algo que suena muy bien, haz la pregunta que este mapa te enseña a hacer: ¿qué regla mía debería revisar esto antes de que se ejecute? Si tienes la respuesta escrita, ya tienes la mitad del trabajo hecho.

Fuentes