El proyecto en resumen
Rol
Proyecto individual · criterio, diseño de pruebas, juicio
Año
Octubre de 2026
Sector
Banca · Productos regulados
Alcance
Accesibilidad (WCAG 2.2 AA) · Heurísticas · Orquestación
Estado
v0.8.0 validada · repositorio público
El problema
En banca, un fallo de diseño puede mover dinero.
Un fallo de usabilidad o de accesibilidad en un flujo bancario no es estético. Puede hacer que alguien autorice una transferencia que no quería hacer, o impedir que una persona que usa lector de pantalla gestione su propia cuenta.
Y, sin embargo, las auditorías de diseño suelen depender de quién las hace. Dos revisores, dos veredictos distintos. Y las herramientas de IA que «revisan diseños» suelen sonar seguras de todo, también de lo que nunca comprobaron.
Mi objetivo era convertir mi criterio de auditoría en agentes que cualquiera del equipo pueda ejecutar y que den resultados que se puedan defender: trazables, repetibles y claros sobre lo que queda sin verificar.
Mi papel
Yo escribí el criterio. La IA lo aplica y yo juzgo el resultado.
Definí la escala de severidad, las reglas de aprobación, las 14 líneas rojas y las lentes de producto regulado. Escribí las hojas de respuestas antes de cualquier prueba, diseñé los casos y juzgué cada ejecución.
Lo construí con Claude Code. Claude redactó y afinó las skills bajo mi revisión; cada regla que llegó a la v0.8.0 es una decisión que tomé y que puedo explicar.
Cómo funciona
Un orquestador, agentes especialistas y dos firmas humanas.
Cada disciplina es una skill: un procedimiento escrito con mi criterio, referencias, una plantilla de informe fija y casos de prueba. El orquestador planifica el trabajo, lo encarga a los especialistas, agrega sus resultados y se detiene cada vez que una persona tiene que decidir.
- 01Reto + pantallaBanco ficticio, flujo real
- 02El orquestador planificaAlcance, fases, preguntas abiertas
- 03 · Decisión humanaUna persona firma el alcanceNada se ejecuta antes
- 04Los especialistas evalúanHeurísticas y accesibilidad, en paralelo
- 05AgregaciónEstado más restrictivo · sin medias · sin duplicados
- 06 · Decisión humanaUna persona firma o acepta el riesgoLos agentes nunca firman por nadie
Agentes de la edición pública
accessibility-auditorLos 55 criterios A/AA de WCAG 2.2 y lentes de fraude, estados inciertos y autenticación reforzadaux-heuristics-expertLas 10 heurísticas de Nielsen, 14 líneas rojas (usabilidad crítica y patrones engañosos) y Leyes de UX como apoyodesign-orchestratorPlanifica, encarga, agrega y se detiene en cada firma humanaDecisiones clave
Las decisiones que lo hacen defendible.
Lo valioso no es «tener un agente». Es el criterio que lleva dentro, y la prueba de que lo aplica.
01
Criterio escrito, no un prompt largo
Cada disciplina es una skill versionada con referencias, plantilla de informe y casos de prueba. El criterio se puede revisar, probar y cambiar como un producto.
02
Una escala de severidad, reglas de aprobación separadas
La severidad significa lo mismo en todas partes. Pero un solo incumplimiento WCAG A/AA confirmado da No apto, y un problema heurístico moderado aislado no. La conformidad no se gradúa.
03
Gana el más restrictivo, sin medias
Un problema que bloquea en una disciplina nunca se compensa con buenos resultados en otra. El informe dice qué evaluación determina el resultado.
04
Un problema se cuenta una vez
«Firmar sin ver importe ni destinatario» es una línea roja heurística y un riesgo de producto. Se informa una vez, conservando el gate más estricto.
05
Firman las personas, no los agentes
Las exclusiones del alcance, las firmas y las aceptaciones de riesgo exigen una decisión humana explícita. Aceptar un riesgo no es resolverlo.
Diseñado contra la confianza ciega
Un auditor de IA que suena seguro es peligroso.
Cómo lo validé
Probado como un producto antes de lanzarlo.
Hojas de respuestas escritas antes. Una sesión nueva por caso. Un aula aislada que dejaba traza de cada archivo leído y cada acción intentada. Una prueba punta a punta del orquestador con 10 criterios de aceptación definidos de antemano.
Problemas sembrados detectados (y 2 más a medias)
Casos de prueba superados · 5 de accesibilidad, 6 de heurísticas
Criterios A/AA de WCAG 2.2 cubiertos en cada auditoría
La prueba punta a punta se aceptó con una incidencia contenida (abajo), sin presentarla como un 10/10 limpio. Dos exámenes resultaron ambiguos: corregí los exámenes y los repetí, en lugar de forzar a los agentes para que pasaran.
Qué falló y qué cambié
Los fallos son donde el criterio se afina.
El agente copiaba de informes anteriores.
→ Ahora cada auditoría es independiente.
Las sesiones guardaban archivos y hacían commits de git que nadie había pedido. Lo descubrí en las trazas, no en los informes.
→ Evaluar, guardar y hacer commit pasaron a ser tres permisos distintos, y los exámenes, a un aula aislada.
Los huecos del enunciado se trataban como indicios de línea roja.
→ El examen estaba mal planteado. Nueva categoría: «información no aportada».
Una ejecución confirmó una línea roja apoyándose en un supuesto propio.
→ Se registró como regresión de aplicación, sin forzar la skill.
«Audita esta pantalla» activó al especialista equivocado.
→ Los tests de una skill declaran la disciplina; los enunciados neutros se reservan para probar el routing.
Un agente sin validar intentó escribir fuera de su carpeta.
→ El control de permisos lo bloqueó. Se aceptó como incidencia contenida y pasó al backlog.
Demo
Planifica, y se niega a firmar por ti.
Una sesión real, recortada y acelerada. Producto intenta aceptar el riesgo de firmar sin ver el importe ni el destinatario. El orquestador lo rechaza: el riesgo aún no se ha evaluado, y una aceptación necesita responsable, justificación, alcance y condiciones.
Lo que me llevo
El criterio es el producto.
01
El criterio es el producto
El agente es solo el vehículo. Lo que se transfiere a un equipo es el juicio escrito lo bastante bien como para poder probarlo.
02
Prueba el examen antes que el agente
Dos de mis «fallos del agente» eran exámenes mal diseñados. Corregir la prueba era el arreglo honesto.
03
Lee las trazas, no solo las respuestas
El problema más grave, los commits no pedidos, no aparecía en los informes. El comportamiento necesita su propia evidencia.
Un auditor de IA es tan fiable como lo que admite que no pudo comprobar.
Siguiente: un agente de design system (multimarca, tokens, Web Components y React), validado con el mismo método, y nueva evidencia de consistencia entre ejecuciones repetidas y frente a herramientas automáticas.
Edición pública de la v0.8.0. La demo usa Banco Lumen, un banco ficticio: no aparece ningún banco, cliente ni persona real. No sustituye las pruebas con personas usuarias ni con personas que usan tecnologías de apoyo.