Gobernanza del design system para agentes de IA: 6 reglas para 2026

Un design system legible por máquinas es un design system publicado como datos estructurados (tokens, un manifiesto de componentes, reglas de uso) que los agentes de IA de programación consultan a través de una interfaz como un servidor MCP. Así, las interfaces que generan usan los componentes y las decisiones que el equipo ya ha aprobado. Cuando lo leen agentes, el design system funciona como una API: tiene usuarios que no pueden preguntar a un compañero, no adivinan intenciones y fallan con cada cambio sin documentar.

Esto afecta a quien mantiene un design system y ya ve a Cursor, Claude Code o Copilot escribir pantallas con sus componentes. Las herramientas llegaron rápido. El servidor MCP de Figma pasa a los agentes variables, componentes y las correspondencias de Code Connect. Storybook genera un manifiesto JSON de componentes para su servidor MCP. Google Labs publicó DESIGN.md como formato abierto. La gobernanza se pensó para lectores humanos y se ha quedado atrás. Esto es lo que cambia, y estas son las seis reglas que aplicamos.

¿Qué cambia cuando quien lee el design system es un agente?

Un lector humano rellena los huecos. La diseñadora que encuentra dos tonos del mismo azul pregunta cuál es el vigente. El desarrollador que ve una prop obsoleta en Storybook lee la nota y sigue. Un agente no hace ninguna de las dos cosas. En la AI Design Systems Conference 2026, los ponentes señalaron como primer fallo la deriva de la documentación: cuando la documentación, los tokens y los componentes no coinciden, el agente se queda con la primera fuente que encuentra, según el resumen de las charlas que publicó Into Design Systems. En el mismo resumen, Romina Kavcic calcula que el mantenimiento puro se lleva entre el 30 y el 40 % del tiempo de un equipo de design system.

De ahí salen tres consecuencias.

• La deriva acaba en el producto. Una incoherencia que antes costaba un comentario en la revisión ahora aparece en cada pantalla que genera un agente.
• La prosa pierde frente a la estructura. Una nota de uso dentro de un párrafo es un consejo para una persona y ruido para un modelo que busca un campo.
• Cada cambio tiene usuarios que no ves. Prompts, archivos de reglas y contextos guardados en una docena de editores dependen de nombres que alguien podría cambiar cualquier martes.

De qué está hecho un design system legible por máquinas en 2026

De cuatro piezas, cada una con un formato que se ha asentado en el último año.

• Tokens. El Design Tokens Community Group publicó la primera versión estable de su especificación, la 2025.10, el 28 de octubre de 2025. Define un formato JSON neutral respecto a los proveedores, con alias, temas y una propiedad $deprecated que una herramienta o un agente puede leer.
• Manifiesto de componentes. Storybook genera manifiestos, objetos JSON que listan cada componente con sus props, historias y documentación, y los sirve a los agentes a través de su servidor MCP. Storybook presenta la función como preview, y el esquema del manifiesto todavía no es una API pública estable.
• Contexto de diseño. Con el servidor MCP de Figma, los agentes leen las variables, los componentes y las capturas de un archivo, y Code Connect vincula cada componente de Figma con el componente de código que lo implementa.
• Reglas y motivos. DESIGN.md, que Google Labs liberó como código abierto, pone los tokens en un front matter YAML y los motivos de cada decisión en prosa Markdown. Su esquema todavía declara la versión "alpha". Los archivos AGENTS.md llevan del mismo modo las instrucciones del repositorio.

Murphy Trueman hizo la cuenta: la misma decisión de diseño puede vivir hoy en cinco sitios, y la mayoría de los equipos no tiene claro quién responde de la parte que leen los agentes. Ahí está el hueco de gobernanza.

¿Importa el formato?

Sí, y hay datos. Diana Wolosin, de Indeed, extrajo 77 componentes de la documentación en MDX y lanzó 1.056 prompts sobre ocho configuraciones de MCP. Con Markdown, cada consulta costaba unos 30.000 tokens, cubría el 82 % de las respuestas y producía alucinaciones. Con metadatos en JSON, las respuestas fueron más precisas con un 80 % menos de tokens y un coste anual unas cinco veces menor, según recoge Into Design Systems. La regla práctica que sale de ahí: los datos estructurados (props, variantes, tamaños, valores permitidos) van en JSON; los motivos se quedan en prosa, para cuando el modelo necesita el porqué.

Las seis reglas de gobernanza

1. Una sola fuente, y todo lo demás generado

Para cada tipo de decisión se elige una fuente y el resto se genera a partir de ella. Los valores de los tokens viven en el archivo JSON en formato DTCG; las variables de Figma, las custom properties de CSS, el front matter de DESIGN.md y las referencias a tokens del manifiesto salen de la build. Las API de los componentes viven en el código, y el manifiesto se obtiene del código y de sus historias. Un archivo que lee un agente y que una persona edita a mano acaba divergiendo, y el agente sigue fiándose de él. En los archivos escritos a mano queda solo lo que no se puede derivar: la intención, las concesiones, los casos en que un componente es la elección equivocada.

2. Versionar lo que leen los agentes como una API pública

El versionado semántico se aplica también a lo que leen los agentes, junto con el paquete. Renombrar un token, quitar una variante o cambiar los valores permitidos de una prop es un cambio mayor para un agente, aunque el resultado visual sea idéntico, porque los archivos de reglas y los prompts citan el nombre antiguo. Primero se marca como obsoleto, después se elimina, y el sustituto se escribe en los datos: una cadena $deprecated en el token con el nombre de su sucesor, un campo deprecated en el componente que apunta al nuevo. Los agentes leen campos. El changelog rara vez les llega.

3. Un solo responsable de lo que leen los agentes

En la descripción de Trueman, los tokens suelen quedarse en el equipo de design system y AGENTS.md en ingeniería, mientras que la configuración MCP de Figma se queda con quien la instaló. Cuando nadie responde del conjunto, nadie se da cuenta de que el manifiesto dejó de regenerarse hace tres versiones. Una persona o un equipo aprueba cada cambio en lo que leen los agentes, con la revisión que recibe un cambio en una API pública. El modelo de gobernanza para un design system con muchos proyectos consumidores sirve aquí tal cual: los agentes son un consumidor más, y el más literal.

4. Escribir las reglas de uso como datos

«Usa el botón destructivo solo para acciones irreversibles» es una frase. {"intent": "destructive", "use_when": "the action cannot be undone", "requires": "confirmation dialog"} es una regla que un agente puede comprobar. Toda regla con respuesta de sí o no sale de la prosa y pasa a campos: cuándo usarlo, cuándo no, qué necesita al lado, con qué sustituirlo. La prosa se queda para las decisiones de criterio. Los equipos que ya siguen una convención estricta de nombres de tokens tienen la mitad del trabajo hecho, porque el nombre ya lleva la intención.

5. Decidir qué puede cambiar un agente

Los agentes ya proponen cambios en los design systems: actualizaciones de tokens, correcciones de documentación, historias nuevas. Conviene dejar por escrito qué cambios puede hacer un agente y en qué condiciones. Un reparto presentado en la conferencia: corrección automática para cambios de bajo riesgo, como errores de lint y etiquetas de accesibilidad; pull requests en borrador para valores de tokens y descripciones; y solo sugerencias para API nuevas de componentes, cambios incompatibles y decisiones de gobernanza. En GitHub, los agentes que trabajan en el design system Primer pueden abrir una issue, pero no hacer merge de código, según el mismo resumen.

6. Probar lo que producen los agentes, en cada versión

Antes un design system se probaba en su propio límite: el componente se renderiza, pasa las comprobaciones de accesibilidad. Con agentes, el límite se desplaza al resultado. Se mantiene un conjunto fijo de prompts (una página de ajustes, una tabla de precios, un empty state) y se lanza contra lo que leen los agentes en cada versión. En la interfaz generada se buscan componentes que no existen, valores hexadecimales escritos a mano y props fuera de los valores permitidos. El servidor MCP de Storybook ya va en esa dirección: el agente escribe historias de lo que ha generado y les pasa pruebas de interacción y de accesibilidad. Con una comprobación en CI que falla cuando el manifiesto, los tokens y el código no coinciden, el component drift aparece como una build fallida antes de aparecer en una pantalla generada.

Cómo se ve en un solo componente

Pongamos un Button con una prop variant que antes admitía danger y ahora usa destructive. Con una gobernanza pensada para personas, el cambio de nombre sale con una línea en el changelog y un codemod. Con una gobernanza de API, en la misma versión cambian cuatro cosas:

1. El código sigue aceptando danger durante una versión mayor y lo marca como obsoleto en los tipos.
2. El manifiesto, regenerado desde el código, lista danger como obsoleto y destructive como sustituto.
3. El token button.danger.background lleva "$deprecated": "Use button.destructive.background".
4. Se ejecuta la batería de prompts, y cualquier pantalla generada que todavía escriba danger no pasa la comprobación.

El cambio de nombre cuesta una tarde más. A cambio, ningún agente sigue meses generando el nombre antiguo desde un contexto caducado.

Cuándo todavía no compensa

Un equipo con un solo producto, pocos componentes y ningún agente escribiendo interfaces saca poco de manifiestos y baterías de prompts. El coste es real: pipelines para generar archivos, una revisión en cada cambio de metadatos, una batería de pruebas que mantener. Dos señales indican que ha llegado el momento: los agentes ya generan pantallas en el código, o el design system sirve a más de un producto. En los dos casos, la parte que leen los agentes existe igualmente, la gobierne alguien o no, y el trabajo descrito aquí cuesta menos que arreglar lo que produce sin reglas. Hemos tratado el paso del diseño al código en la guía del servidor MCP de Figma y el lado de la interfaz en diseñar la UI para agentes de IA.