Una demo es el peor momento para evaluar un sistema de IA. Ves lo que el sistema sabe hacer, con un ejemplo que ha elegido el propio proveedor. En el trabajo de conocimiento importa sobre todo lo que un sistema no hace: no inventar una fuente, no cambiar un texto sin que nadie lo note, no llevarse tus datos a un lugar que desconoces. Una demo no lo enseña. Eso está en la documentación y en el contrato, o no está en ningún sitio.
Por eso, envía las preguntas antes de la demo y por escrito. Una respuesta escrita puede compararse con la de un segundo proveedor, adjuntarse al contrato y releerse un año después. Además, una respuesta vaga se nota mucho más en el papel que en una reunión en la que alguien va pasando pantallas con entusiasmo.
Seis capas, seis preguntas
Las preguntas siguen TRACES, el modelo con el que VergeLabs evalúa cualquier sistema.
TRACES son las seis capas con las que evalúas un sistema de IA: Trail, Retrieval, Approval, Constraints, Expertise, Storage. Donde falta una capa, hay un riesgo.
Para cada capa encontrarás abajo la pregunta que puedes copiar tal cual, lo que contiene una respuesta útil y cómo suena una respuesta evasiva. Esto último es igual de práctico, porque las respuestas evasivas se parecen entre sí, las dé el proveedor que las dé.
T · Trail
La pregunta. ¿Qué registra el sistema en cada respuesta y en cada cambio: la fuente, la afirmación, quién la aprobó y cuándo? ¿Y podemos exportarlo?
Útil. Una lista de los campos, un ejemplo de exportación y el compromiso de que el rastro se genera solo mientras alguien trabaja. Si un empleado tiene que mantenerlo a mano, en una semana de mucho trabajo simplemente no se hará.
Evasiva. «Todo queda registrado.» Insiste: un registro de quién inició sesión y cuándo no es lo mismo que un rastro de qué afirmación se apoya en qué fuente.
R · Retrieval
La pregunta. ¿De qué fuentes responde el sistema, y qué pasa cuando la respuesta no está en ellas?
Útil. Responde solo a partir de una colección que delimitáis vosotros, con una referencia al pasaje en cada respuesta y un «no lo sé» cuando ese pasaje no existe. Mejor aún: el sistema puede mostrar qué afirmaciones de un texto no tienen fuente. Buscar, por sí solo, nunca puede demostrar una ausencia.
Evasiva. «Las alucinaciones se reducen al mínimo.» O: «El modelo está entrenado con datos fiables.» Las dos respuestas hablan del modelo, no de vuestras fuentes.
A · Approval
La pregunta. ¿En qué punto del trabajo confirma una persona el contenido, varía según el tipo de cambio y se registra esa confirmación?
Útil. Una descripción del momento de aprobación, por pasaje o por tipo de cambio, con la fuente al lado. Corregir una errata no exige criterio experto; reescribir una cifra, sí.
Evasiva. «El usuario sigue siendo siempre el responsable.» Eso es un aviso legal, no una función.
C · Constraints
La pregunta. ¿Qué acciones no puede ejecutar el sistema técnicamente, aunque un usuario se lo pida?
Útil. Una lista corta, por ejemplo enviar, publicar, comprometerse con un cliente o sacar datos del entorno propio. Con la explicación de que ese bloqueo está en el software, fuera del modelo.
Evasiva. «Se ha instruido al modelo para que no lo haga.» Una instrucción es una petición. Un modelo al que se le prohíbe algo sigue pudiendo hacerlo en principio; un sistema que no puede, no puede.
E · Expertise
La pregunta. ¿Qué decisión se queda con nuestros especialistas, y cómo hace el sistema que esa decisión resulte más ligera?
Útil. Una decisión concreta, como la conclusión, la valoración o el visto bueno, y una ayuda específica para tomarla. Por ejemplo, el pasaje de la fuente junto a la afirmación, para que nadie tenga que leerse la fuente entera.
Evasiva. «El sistema te quita el trabajo de pensar.» Para un trabajo que sale con vuestro nombre, es justo el argumento equivocado.
S · Storage
La pregunta. ¿Dónde se almacenan nuestros datos, se usan para entrenar modelos y en qué cláusula de qué contrato consta?
Útil. Una región, una lista de subencargados del tratamiento y una referencia a una cláusula del contrato de encargado del tratamiento.
Evasiva. «Nos tomamos la privacidad muy en serio.» O «conforme al RGPD», sin ningún documento que lo acompañe.
Cómo leer las respuestas
Da a cada respuesta una de tres valoraciones: presente, parcial o ausente. Presente significa que la respuesta es concreta y que la encuentras en un documento. Parcial significa que la función existe pero hay que preguntar más, o que solo se prometió de palabra. Ausente es una respuesta evasiva, o ninguna respuesta.
No todas las capas pesan igual. Cuál pesa más depende de dónde es vulnerable vuestro propio trabajo, y eso lo muestra el segundo modelo. SEAL describe las cuatro fases por las que pasa el trabajo de conocimiento: Source, Edit, Approve, Launch.
SEAL muestra qué fase tiene una fuga. TRACES es la manera de comprobar si un sistema puede cerrar esa fuga.
Si la fuga está en Source, porque nadie anota de dónde sale una afirmación, no puedes prescindir de Retrieval. Si está en Edit, porque tras reescribir un texto ya no se contrasta con la fuente, se trata de Trail y Approval. Un sistema que puntúa como ausente justo en esa capa queda descartado, por bueno que sea el resto.
Qué puedes hacer esta semana
- Elige el sistema que estáis considerando. Uno que ya uséis sirve igual de bien.
- Mete las seis preguntas en un único correo al proveedor. Pide respuestas por escrito, con una referencia a la documentación o al contrato siempre que sea posible.
- Pon las respuestas en una tabla con tres columnas: capa, respuesta, valoración.
- Cuenta las capas valoradas como ausentes. Si una de ellas es la capa que más pesa para vosotros, ya sabes lo suficiente.
Si prefieres revisar antes tú mismo la documentación pública, el Escáner de Proveedores de esta web pasa un sistema por las mismas seis capas.