¿Has construido algo en un fin de semana que te habría llevado un trimestre?
Una iglesia colaboradora tenía una lista de prioridades. En algún lugar de esa lista figuraba un panel de control ejecutivo: asistencia de adultos y niños, eventos, participación de voluntarios, todo en una sola vista. Iba bajando cada vez más en la lista, como suele ocurrir con cualquier prioridad cuando hay otras tres cosas que también lo son. Así que, mientras nosotros nos ocupábamos de lo que teníamos entre manos, ellos no se quedaron de brazos cruzados. Programaron ellos mismos el panel de control.
Lo abrimos y todo estaba bien. Habían comprobado las cifras, las habían cotejado con los datos que Rock tenía realmente en sus archivos, y todo cuadraba.
Pero en ese panel de control había un indicador clave de rendimiento (KPI) sobre los «miembros activos de grupos pequeños», y eso era lo que nos preocupaba.
«Active» no se ha definido
¿Qué significa «activo» en este contexto? ¿Un miembro del grupo con el estado «activo»? ¿Alguien que haya asistido a cuatro de las últimas ocho semanas?
Tomemos este último ejemplo. Alguien asistió a cuatro de las últimas ocho semanas, y su registro se archivó anoche porque su responsable lo trasladó a otro grupo. El panel de control sigue considerándolo activo. Las cifras son correctas. El registro es real. La persona que lo creó simplemente nunca tuvo motivo para preguntar qué significaba «activo» en este contexto, ni para saber que esa ruta existe en Rock.
Que algo esté comprobado no significa que se entienda.
Seguramente ya hayas visto algo parecido. Quizá no sea un panel de control, sino un informe o un flujo de trabajo que alguien ha creado rápidamente para ahorrar tiempo a todo el mundo.
Esto ya ha pasado, y no fue culpa de la IA
El problema de las vistas de datos
Rock ya había creado su propia versión de esto, años antes de que nadie le pidiera a la IA que creara nada. Probablemente ya te hayas encontrado con una «Vista de datos», la función de Rock que permite guardar una lista de personas o registros que cumplen los criterios que tú establezcas. Una iglesia asociada ofreció a cada miembro del personal del ministerio la posibilidad de crear la suya propia, desde la asistencia durante 60 días hasta las donaciones destinadas a un fondo específico, lo que cada miembro del personal necesitara ese día. Las intenciones eran buenas: más autoservicio y menos solicitudes acumuladas en una cola.
En cuestión de unos meses, todo el mundo tenía su propia versión de lo que significaba «comprometido» y su propia definición de «generosidad». Se elaboraban informes que, aunque técnicamente correctos, discrepaban sutilmente entre sí. Los directivos dejaron de confiar en las cifras que proporcionaba Rock. El problema no era Rock, sino la falta de una estrategia de datos coherente.
Se trata de un problema relacionado con la «fuente de verdad», y es el mismo que se traslada a la forma en que un equipo utiliza la IA. Tampoco se limita únicamente a las vistas de datos.
Esto también ocurre fuera del ámbito de la tecnología eclesiástica
Airbnb se topó con el mismo problemaantes de crear una plataforma centralizada de métricas. Los departamentos de Ciencia de Datos y Finanzas respondían a una pregunta tan sencilla como «¿qué ciudad tuvo más reservas la semana pasada?» con dos cifras diferentes, extraídas de tablas ligeramente distintas y utilizando definiciones ligeramente diferentes. La confianza en los datos se resintió. Y con ella, la confianza de los responsables de la toma de decisiones. La solución no fue una herramienta más inteligente, sino un único lugar del que todos acordaron extraer la información.
Si le pides a la IA que haga el mismo trabajo, la diferencia se nota antes
En el episodio 207 de «Rock Cast», utilizaron este ejemplo como referencia para ilustrar exactamente en qué punto falla el código SQL generado por IA: «Dame todas las cuentas a las que alguien haya hecho una donación. Es como decir: vale, ¿qué cuentas son esas? ¿Cuáles se consideran donaciones?».
Y tampoco se limita al rock. En 2023, dos abogados presentaron un escrito judicial repleto de citas de casos falsos. ChatGPT se las había inventado, y parecían sentencias judiciales reales. Cuando el tribunal les instó a presentar los casos reales, ninguno de los dos abogados los consultó en una base de datos jurídica real, la misma herramienta que todos los abogados ya tienen y están capacitados para utilizar antes de presentar cualquier documento. Uno de ellosle dijo al juez: «Es que nunca se me ocurrió que pudieran ser inventadas». Las citas parecían completas, así que se saltó el paso que le habría permitido detectarlo.
Una herramienta se vuelve más rápida. La confianza en los resultados supera la capacidad de cualquiera para comprobarlos. Un administrador de Rock con experiencia puede detectar la falla porque lleva años aprendiendo exactamente dónde se encuentra. Un miembro del personal que trabaje a buen ritmo por su cuenta, sin esa experiencia y sin motivos para sospechar, probablemente ni siquiera se le ocurrirá preguntar.
El riesgo que te sale caro
Multiplica ese primer panel de control, el que se creó en un fin de semana, por cada equipo y cada miembro del personal bienintencionado que hace lo mismo, cada uno con sus propias definiciones y sin que nadie se encargue de supervisarlo.
Modelos de datos distintos para cada cuadro de mando. Ya no queda nadie que pueda solucionarlo una vez que la persona que lo creó deja el puesto. Definiciones que, sin que nadie se dé cuenta, difieren entre sí de un ministerio a otro.
Eso deja de parecer simplemente que unas pocas personas actúan con rapidez. Empieza a parecer que los informes y las herramientas no inspiran confianza: cifras que no cuadran, paneles de control que se contradicen entre sí. Si eres el directivo que debe respaldar esas cifras, ese es el precio que acabas pagando.
Esto no es un argumento en contra de la construcción
Queremos dejar claro lo que no estamos diciendo.
No estamos diciendo que hay que ir más despacio. Tampoco estamos diciendo que hay que dejar de permitir que tu equipo siga desarrollando. Lanzar un panel de control en un fin de semana en lugar de esperar un trimestre, verificar las cifras y ganar confianza por el camino: eso es un éxito. No queremos disuadir a nadie de hacerlo.
Desarrollar sin que nadie se haga cargo de las definiciones subyacentes es lo que provoca el daño. La IA no creó ese riesgo. Simplemente eliminó el último obstáculo que antes obligaba a alguien a plantear la pregunta primero.
La solución
- Reúne a las personas adecuadas en una sala y convierte las palabras en una fuente de verdad. ¿Qué se considera un miembro activo? ¿Qué se considera «comprometido»? ¿Qué se considera «generoso»? Poneros de acuerdo en una sola definición, no una diferente para cada ministerio, y ponedla por escrito en un lugar donde todos puedan encontrarla. Llámalo «Diccionario del Ministerio»: una lista compartida de términos y definiciones con la que deben coincidir todos los paneles de control, informes o conjuntos de datos generados por IA. A continuación, crea las vistas de datos fundamentales y los conjuntos de datos que la sustentan, de modo que cualquiera que trabaje con Rock, ya sea personal o IA, lo haga sobre una base veraz.
- Adapta la formación a lo que está en juego. No es necesario que todos los miembros de tu equipo realicen el curso «Master Class» de Rock, pero sí que deberían hacerlo algunos, porque alguien tiene que saber qué es realmente posible en Rock antes de que el resto del equipo construya en torno a una limitación que no es real. A veces, la verdadera carencia no es en absoluto el conocimiento de Rock, sino el dominio de la IA. Triumph organiza un programa de formación en flujos de trabajo agenticos de IA precisamente para eso: un pequeño grupo que trabaja conjuntamente en un flujo de trabajo real, con orientación y revisión a lo largo del proceso.
- Evaluar la comprensión, no solo la verificación. Geoffrey Litt deja clara esta distinción: la verificación consiste en preguntarse si algo funciona; la comprensión, en preguntarse si la persona es capaz de explicarlo, ampliarlo y detectarlo la próxima vez que falle. No es seguro basarse en algo que funciona correctamente si la persona que lo ha creado no es capaz de explicar las decisiones que se han incorporado en su diseño.
Si te saltas este orden, acabarás enseñando a la gente a desenvolverse en un caos o proporcionándoles una base que nadie sabe cómo utilizar.
Antes de exigirle más rapidez a tu equipo o a un agente
Hazte primero una pregunta: ¿puede la persona que lo ha creado explicarlo, y no solo decir si funcionaba?
Una estimación puede ser técnicamente precisa y, aun así, errónea, porque «errónea» no siempre significa que sea una cifra incorrecta. A veces se trata de una cifra válida con la que nadie estaba de acuerdo.
La construcción se fue haciendo más fácil. Era de esperar que así fuera.
Entender sobre qué se está construyendo nunca ha sido algo opcional. Simplemente, ahora es más fácil pasar por alto ese paso.