Caso 03
Gobernanza de calidad para la documentación asistida por IA
Mi equipo empezó a usar IA para redactar, traducir y revisar, y nadie registraba los errores que introducía. Monté puntos de control, una bitácora de errores y dos roles para que esos errores cambien los prompts.
- 3
- puntos de control, uno por etapa: borrador, traducción y revisión antes de exportar
- 5
- pestañas del libro: instrucciones, tres listas de chequeo por etapa y una bitácora de errores
- 2
- roles nuevos: TW Revisor y TW de Prompts
Mis decisiones 04
- Limitar el alcance a los tres momentos en los que ya se usaba IA; sin procesos nuevos.
- Usar un libro por pestañas para el trabajo diario y una hoja compartida para la bitácora.
- Cero ambigüedad y nada de complejidad innecesaria, porque el equipo es nuevo en este tipo de flujo.
- Separar a quien aplica los controles de quien responde por los prompts.
Ejecución asistida 01
- Claude construyó el libro: fórmulas, validaciones y formato condicional.
Contexto
Lidero un equipo de dos redactores técnicos. Habíamos empezado a usar IA en tres momentos del flujo: redactar a partir de los requerimientos de Producto, traducir entre español e inglés y revisar antes de exportar a PDF.
En cada momento la IA podía introducir errores: estilos perdidos, secciones faltantes, texto sin traducir, inconsistencias. La revisión era informal y nadie registraba esos errores.
Qué decidí
Mantuve el alcance en los tres momentos que ya existían. No quería sumar procesos a un equipo que todavía aprendía a trabajar con IA. Por la misma razón pedí cero ambigüedad y nada más complejo de lo necesario.
Una lista de chequeo sola es un filtro. Detiene un error una vez, y el mismo error puede volver en la siguiente ejecución. Por eso dividí el trabajo en dos roles: uno aplica los controles y el otro responde por lo que los controles encuentran.
Cómo funciona
- Un libro de cinco pestañas. Una pestaña de instrucciones: propósito, roles, pasos, las secciones estándar que deben preservarse y una guía de seis pasos para reportar un error.
- Tres listas de chequeo, una por etapa. Ítems por categoría, con respuesta sí, no o no aplica, y notas. Cada una tiene un bloque de “señales de prompt” que indica cuándo el error viene del prompt y no de la fuente.
- Una bitácora de errores. Campos validados, un resumen por estado y formato condicional por estado e impacto.
- TW Revisor. Aplica las listas de chequeo.
- TW de Prompts. Vigila la bitácora y ajusta los prompts cuando un error se repite.
El ciclo es bitácora → patrón recurrente → ajuste del prompt, para que la siguiente ejecución empiece mejor.
Qué produjo
Antes, lo que producía la IA recibía una revisión informal. Ahora cada etapa tiene su lista de chequeo, y los errores recurrentes llevan a ajustar los prompts. Cuando RR. HH. me pidió describir mi rol, señalé que esta bitácora es lo único que mi área registra formalmente hoy.
Lo que aún no prueba
El sistema está en uso, pero no he medido su efecto. No tengo el conteo de errores por etapa ni por mes, ni la tasa de aprobación al primer intento, ni cuántos errores recurrentes llevaron a cambiar un prompt.
Qué haría después
Sacar esas tres cifras de la bitácora cada mes. Si los ajustes de prompt funcionan, los mismos errores deberían aparecer cada vez menos; si no, la bitácora lo va a mostrar.