Auditoría AI-readiness de un design system en 7 pasos

Qué mide una auditoría AI-readiness

AI-readiness no es una opinión sobre la calidad del sistema: es una medida de cuánto del sistema puede consumir un agente sin intervención humana. Un sistema puede ser excelente para personas (documentación cuidada, onboarding eficaz, comunidad activa) y opaco para agentes, porque todo lo valioso vive en formatos que un modelo no puede consultar: capturas, vídeos, memoria institucional.

La auditoría recorre 7 ejes. Cada uno se puntúa de 0 a 3 (0: no existe; 1: existe pero no es legible por máquina; 2: legible pero incompleto; 3: legible, completo y versionado). El resultado es un número sobre 21 y, más útil que el número, la lista ordenada de huecos.

Paso 1 — Inventario de fuentes de verdad

Lista dónde vive cada tipo de conocimiento del sistema: tokens, componentes, principios, patrones, decisiones. Para cada uno, anota el formato (JSON, TypeScript, Figma, Notion, Confluence, vídeo) y si tiene una URL estable.

El hallazgo típico: el 60% del conocimiento operativo no tiene fuente canónica única. Hay tokens en Figma y en código que divergen, y la versión “buena” la conoce una persona. Un agente no puede arbitrar entre fuentes que se contradicen; puntúa 0 todo conocimiento sin fuente única.

Paso 2 — Tokens: formato y semántica

Comprueba tres cosas sobre la capa de tokens:

Formato. ¿Es W3C DTCG ($value, $type, $description) o un dialecto propietario? Si usas Style Dictionary, la versión importa: la 4 lee DTCG nativo, la 3 no (detalle de la migración).
Tipado. ¿Qué porcentaje de tokens declara $type? Sin tipo, #FF0000 es una cadena cualquiera.
Metadata operativa. ¿Las reglas de uso (contraste mínimo, superficies permitidas) viajan en $extensions o solo en la documentación? Lo segundo puntúa 1, no 3.

Paso 3 — Componentes: API legible por máquina

Para cada componente público, ¿existe una descripción estructurada de su API (props, variantes, restricciones) en un formato consultable? Valen los tipos TypeScript exportados, un JSON por componente o un custom-elements manifest. No valen las tablas de props renderizadas en HTML de Storybook sin fuente estructurada detrás.

Prueba rápida: pide a un agente que genere un uso del componente más complejo del sistema sin acceso al código fuente, solo con lo que el sistema publica. Cuenta cuántas props inventa.

Paso 4 — Principios ejecutables

Lee los principios del sistema y aplica un filtro binario a cada uno: ¿puede un agente decidir si una composición concreta lo cumple o lo viola? “Sé claro” no pasa el filtro. “El cuerpo de texto no baja de 16px y el contraste no baja de 7:1” sí. El procedimiento de reescritura está en cómo escribir principios que un agente pueda aplicar.

Puntúa el eje por proporción: si 2 de 8 principios son ejecutables, el eje está en 1.

Paso 5 — Exposición: llms.txt y MCP

¿Cómo accede un agente externo a todo lo anterior? Dos niveles:

Estático. ¿Existe llms.txt en la raíz del sitio de documentación, con enlaces a tokens, principios y APIs en crudo? Coste de una tarde.
Dinámico. ¿Existe un MCP server que exponga tokens como resource y APIs como tools? Coste de un sprint; la anatomía mínima está documentada.

Un sistema sin ninguno de los dos obliga a cada equipo consumidor a improvisar su propio scraping, con resultados divergentes.

Paso 6 — Governance del flujo agéntico

Revisa las políticas escritas (no las costumbres) sobre tres preguntas: qué pueden consumir los agentes, qué pueden proponer y quién revisa lo que proponen. Si la respuesta a las tres es “no está escrito”, el eje puntúa 0 aunque en la práctica el equipo lo haga bien: una regla no escrita no escala a un consumidor que no asiste a reuniones. El marco completo está en governance agéntica.

Paso 7 — Score y plan de cierre

Suma los 6 ejes anteriores más este: ¿existe un owner del AI-readiness con presupuesto de tiempo asignado? Con el total sobre 21:

Score	Lectura	Primera acción
0-7	El sistema es opaco para agentes	Paso 1: consolidar fuentes de verdad
8-14	Consumible con fricción alta	Pasos 2 y 5: tipar tokens y publicar llms.txt
15-21	Listo para flujo agéntico	Paso 5 dinámico: MCP server versionado

El plan de cierre ordena los huecos por coste-impacto: llms.txt y el tipado de tokens suelen ser las dos primeras tareas en el 80% de las auditorías, porque cuestan días y benefician a todos los consumidores a la vez. Repite la auditoría cada 6 meses: el score baja solo, porque el sistema cambia más rápido que su capa de exposición.

Ver también

Este procedimiento es el contenido de la mini-formación de auditoría AI-readiness: 3 horas grabadas, plantilla JSON y rúbrica, para producir el diagnóstico de tu sistema en una sentada. Si el plan de cierre exige acompañamiento, el bootcamp ejecutivo lo cubre en 8 semanas.