Alucinación
Cuando una IA da una respuesta que suena convincente pero es falsa o se la ha inventado. En diseño con agentes se reduce dándole datos reales con los que trabajar (tokens, reglas) y comprobando después lo que produce, para que improvise lo menos posible.
En una analogía · Es cuando alguien te responde con mucha seguridad algo que se ha inventado: suena bien, pero no es verdad.
También conocido como: hallucination
El mecanismo: por qué inventa, y por qué no avisa
Un modelo de lenguaje no consulta una base de datos: completa texto probable. Si le pides “el token de color para error” y no puede leer tu sistema, generará el nombre que suene más plausible (color-error-500, feedback.danger), exista o no. Y lo afirmará con la misma seguridad que una verdad, porque la seguridad del modelo mide probabilidad de texto, no certeza del dato.
En un design system la alucinación tiene formas muy concretas: un token que no existe, una prop inventada de un componente real, un patrón deprecado citado como vigente, un valor hex “de memoria” que se parece al tuyo. Ninguna de las cuatro se nota a simple vista: todas compilan en la cabeza del lector.
La defensa, en dos capas
Antes (grounding): el agente consulta, no recuerda. La diferencia se ve en el flujo:
Sin grounding: prompt → modelo → "color-error-500" (inventado, suena bien)
Con grounding: prompt → MCP: listar tokens de feedback
→ sistema: color.feedback.error, color.feedback.warning
→ modelo elige entre lo que EXISTE
Eso es exactamente lo que hace un MCP server delante de tu sistema: convertir “recuerda mi design system” en “consúltalo”.
Después (validación): lo generado se comprueba contra el sistema. Un test que rechaza cualquier token, componente o prop que no esté en la fuente única de verdad. Es la parte que no depende de la buena conducta del modelo: aunque alucine, no pasa.
Una prueba que puedes hacer hoy, sin tocar nada: pídele a tu asistente los tokens de espaciado de tu sistema. Compara la respuesta con el archivo real. La distancia entre ambas listas es tu exposición actual a la alucinación.
Cómo se reduce, en tres pasos
- Dale acceso real: expón tokens y componentes por MCP o, como mínimo, pega el archivo de tokens en el contexto. Prohibido “de memoria”.
- Valida el output contra el sistema con un guardrail mecánico: existe o no existe, sin juicio.
- Mide la tasa: cuenta cuántos outputs del mes citaron algo inexistente. Ese número decide cuánta autonomía puede subir el agente en la escalera.
Lecturas de referencia
A seguir
Seguir leyendo
- GuíaCómo se implementa un MCP server para tu design systemAnatomía mínima de un servidor Model Context Protocol que expone los tokens, principios y componentes de tu sistema a un cliente agéntico.
- GuíaAuditoría AI-readiness de un design system en 7 pasosProcedimiento completo para diagnosticar si un design system existente es consumible por agentes: fuentes de verdad, tokens, APIs de componente, principios, exposición, governance y plan de cierre.
- GuíaFigma MCP para design systems: el circuito diseño-código sin handoffQué expone el servidor MCP de Figma, cómo lo consume un agente como Claude Code o Cursor, y qué tiene que tener tu design system para que el circuito funcione de verdad.
Recibe la próxima guía en tu correo
Una guía operativa nueva cada poco: cómo se construye, qué decisiones implica y qué no se hace. Sin ruido, solo cuando hay algo útil.