Capítulo 01: Producto con IA: problema, métrica, coste y riesgo

El último error caro

Después de diez facsímiles, ya sabemos hablar de modelos, tokens, RAG, agentes, trazas, evaluación, datos, gobernanza y refuerzo. Ahora viene una pregunta menos vistosa, pero más decisiva: ¿merece la pena construir esta función con IA?

Parece una pregunta de producto. En realidad es una pregunta de ingeniería. Una mala decisión de producto se convierte en deuda de arquitectura. Una promesa demasiado amplia se convierte en una evaluación imposible. Una experiencia sin límites se convierte en soporte, frustración y coste. Y una métrica bonita, si mide lo equivocado, empuja al equipo a mejorar justo lo que no debía mejorar.

Este facsímil cierra el libro porque la IA útil no empieza al elegir modelo. Empieza antes: cuando sabemos formular un problema, acotarlo, medirlo, operarlo y decidir cuándo no construir.

Qué no es una función de IA

Una función de IA no es un botón con una palabra moderna. Tampoco es una caja de texto libre pegada a una pantalla. Y, sobre todo, no es una excusa para no diseñar el flujo normal de trabajo.

Si el usuario ya sabe exactamente qué quiere, los datos están estructurados y la respuesta correcta sale con una consulta SQL, un modelo generativo puede añadir coste y variabilidad sin aportar valor. Si la tarea exige modificar un sistema externo, necesitas permisos, contratos, trazas y política de retorno. Si el problema es que la pantalla es confusa, un asistente conversacional puede taparlo durante una demo y empeorarlo en uso real.

Un buen criterio de producto empieza comparando alternativas:

La IA entra cuando su variabilidad resuelve una variabilidad real del problema: lenguaje natural, ambigüedad razonable, evidencia dispersa, síntesis, priorización, traducción entre formatos, búsqueda semántica o asistencia en tareas donde la persona conserva criterio.

El AI-fit como contrato de producto

Llamaremos AI-fit al encaje entre necesidad, capacidad, evidencia y operación. No basta con que un modelo pueda producir una respuesta. Tiene que existir una razón para usar IA, una forma de medir mejora, una forma de limitar coste y una forma de mantener el sistema cuando cambien datos, modelo o usuario.

La norma ISO 9241-210 define el diseño centrado en las personas como un enfoque que considera usuarios, tareas y entornos durante el ciclo de vida de sistemas interactivos.¹ Traducido a IA: no diseñamos “una respuesta”; diseñamos una tarea completa donde una persona entiende qué puede pedir, qué obtiene, cuándo dudar, cómo corregir y qué queda registrado.

El NIST AI RMF propone gestionar riesgos de IA durante diseño, desarrollo, despliegue y uso mediante funciones como gobernar, mapear, medir y gestionar.² Para producto, eso significa que una idea no pasa a roadmap por sonar moderna. Pasa si podemos mapear contexto, medir calidad, gestionar límites y gobernar cambios.

El AI-fit, por tanto, tiene cinco contratos:

Si falta uno, no tenemos producto con IA. Tenemos una promesa.

Fecha de corte y fuentes consultadas

Fecha de corte: 10 de junio de 2026.

Para este capítulo usamos marcos estables de diseño centrado en personas, interacción humano-IA, gestión de riesgos y experimentación de producto. Lo cambiante no es la idea de medir valor, coste y experiencia; lo cambiante son herramientas, proveedores, precios, modelos y límites de cada plataforma.

Las fuentes consultadas ese día incluyen NIST AI RMF, Microsoft HAX Toolkit y People + AI Guidebook de Google. Microsoft HAX describe herramientas para equipos que construyen productos de IA orientados a usuarios, incluyendo guías, patrones, workbook y playbook para anticipar fallos de interacción.³ Google PAIR organiza el diseño de IA alrededor de necesidades humanas, datos, modelos mentales, feedback, control y evaluación.⁴

El patrón común es simple y exigente: no diseñes una capacidad aislada; diseña una tarea, sus límites, su medición y su recuperación.

De idea a decisión: una taxonomía útil

Antes de entrar en métricas, conviene clasificar la función. No es lo mismo una sugerencia que una acción. No es lo mismo buscar evidencia que modificar un expediente. Tampoco es lo mismo ayudar a redactar que cerrar una solicitud.

Esta tabla evita una trampa habitual: llamar “agente” a todo. Producto debe elegir la intervención mínima que resuelve la tarea con suficiente calidad y coste aceptable.

Un caso completo: matrícula, normativa y respuesta sustentada

Veamos una situación concreta. Un equipo académico recibe solicitudes de matrícula con dudas repetidas: ampliaciones, pagos pendientes, plazos, excepciones y documentación que falta. El equipo quiere reducir tiempo de resolución, pero no puede perder evidencia: cada respuesta debe apoyarse en normativa vigente o en datos del expediente.

La propuesta inicial suele sonar así:

“Pongamos un asistente de IA para resolver solicitudes.”

Eso todavía no es un producto. Es una dirección. Para convertirlo en producto tenemos que comparar alternativas, medirlas y decidir qué versión merece piloto.

Fíjate en la diferencia. Las tres opciones hablan del mismo problema, pero no tienen el mismo riesgo ni la misma evaluación. El buscador compite contra la IA. El RAG entra si realmente mejora tiempo y evidencia. La tool de cierre automático no se rechaza porque “la IA sea mala”; se rechaza porque la acción tiene más consecuencia que la evidencia disponible.

La primera decisión madura sería:

Piloto limitado del RAG con citas para solicitudes con evidencia documental recuperable. Mantener buscador como baseline, no cerrar solicitudes automáticamente, registrar trazas, medir abstención y revisar casos incompletos.

Ese párrafo ya huele a producto. Tiene alcance, alternativa, intervención, límites y evidencia.

Decisiones malas, mejores versiones

Una forma rápida de mejorar una propuesta de IA es obligarla a decir qué tarea resuelve, qué no promete y cómo se revisa. La tabla siguiente recoge patrones que aparecen mucho en proyectos reales.

Este tipo de tabla no es burocracia. Es diseño de producto en modo ingeniería: transforma una intuición en una decisión revisable.

Ejemplo de fórmula: valor esperado de producto

Una cuenta útil para decidir no es perfecta, pero obliga a pensar. Esto es un ejemplo de fórmula de producto, no una ley universal: sirve para hacer explícitas hipótesis de valor, coste y riesgo antes de enamorarnos de una demo.

Con números:

El resultado no dice “publica”. Dice: hay margen si las hipótesis son reales. Ahora toca probar $p_{ok}$, revisar el coste, acotar tareas y comprobar si los errores son reversibles.

Ejemplo de fórmula: en ingeniería de producto conviene calcular el valor por slice:

La media global puede ocultar que el producto funciona muy bien en consultas simples y muy mal en solicitudes críticas. Esa es una lección que viene de evaluación, datos y refuerzo: las decisiones no deberían apoyarse solo en promedios cómodos.

La unidad económica completa

El coste real de una función de IA no es el precio de una llamada al modelo. Esa llamada es una línea de una cuenta más amplia. Ejemplo de fórmula: en un producto con RAG, tools y revisión, el coste por tarea útil debería parecerse más a esto:

Con esos números:

Esta cifra cambia la conversación. Un asistente que parece barato por llamada puede ser caro por tarea útil si necesita demasiados reintentos, revisión o soporte. Y al revés: un modelo más caro puede ser mejor producto si reduce errores, herramientas innecesarias y revisión.

La unidad económica también debe distinguir coste medio y coste de cola. Si el 80 % de solicitudes cuesta 0,18 EUR pero el 5 % complejo cuesta 2,40 EUR por retrieval, herramientas y revisión, el promedio puede ocultar el problema operativo. Por eso el gate no debería mirar solo media: debería mirar P50, P95 y coste por slice.

Análisis de sensibilidad: cuándo deja de compensar

Una unidad económica no está completa hasta que sabes qué variable la rompe. El número final tranquiliza demasiado: parece una verdad, pero normalmente es una mezcla de hipótesis. En un producto con IA, algunas hipótesis cambian rápido: el coste por token, el número de reintentos, la tasa de recuperación, la revisión humana, la latencia, la calidad del retrieval o el porcentaje de casos que realmente quedan resueltos.

La primera pregunta práctica es: qué probabilidad mínima de éxito necesito para que la función tenga sentido económico. Ejemplo de fórmula: si el valor por tarea es $V$ y los costes completos por tarea son $C_{uso}$, $C_{ops}$ y $C_{riesgo}$, el umbral mínimo queda:

Con esos números:

Eso no significa que 0,41 sea suficiente para publicar. Significa que por debajo de 0,40 ni siquiera aguanta la cuenta básica. En un sistema real pediríamos más margen porque las estimaciones son imperfectas, los casos no son idénticos y la cola operativa suele aparecer tarde.

Si usamos la candidata del kit matricula_rag_assistant, cuyo coste completo estimado es 0,31 EUR por tarea y cuyo valor por tarea es 1,10 EUR:

La lectura correcta es: la función tiene margen económico si mantiene calidad y coste bajo control, pero todavía debe pasar guardrails de evidencia, recuperación, privacidad y operación. La unidad económica no sustituye al release gate; lo alimenta.

Este análisis convierte una opinión en una hipótesis falsable. En vez de decir “parece útil”, el equipo puede decir: “si el coste P95 supera 0,55 EUR o $p_{ok}$ cae por debajo de 0,70 en pagos pendientes, no escalamos”. Esa frase es ingeniería de producto: una decisión con umbral, observación y consecuencia.

Métrica norte y guardrails

Una métrica norte es útil cuando concentra una decisión de valor. Es peligrosa cuando se vuelve el único número. Goodhart resumió el problema en política monetaria: cuando una medida se convierte en objetivo, puede dejar de ser buena medida.⁵

En IA pasa constantemente. Si optimizas “uso del asistente”, puedes empujar a la gente a usarlo aunque no resuelva. Si optimizas “respuestas largas”, puedes premiar texto sin evidencia. Si optimizas “menos escalados”, puedes esconder casos que deberían revisarse.

Por eso necesitamos métricas por capas:

Kohavi y coautores explican que los experimentos controlados en web exigen métricas bien definidas y protocolo para evitar conclusiones débiles.⁶ Las plataformas de experimentación a escala añaden otra lección: no basta con lanzar pruebas; hay que gestionar asignación, métricas, análisis, calidad de datos y comunicación de resultados.⁷

En funciones de IA esto es todavía más importante: una mejora en satisfacción puede esconder más coste, una reducción de tiempo puede esconder más errores, y una respuesta más rápida puede ser peor si el usuario pierde capacidad de recuperación.

Métricas buenas y antimétricas

Una métrica buena representa una tarea valiosa. Una antimétrica parece útil, pero puede empujar al sistema hacia una conducta pobre. Conviene escribir ambas antes del piloto.

Esta tabla debería existir en cualquier PRD serio de IA. No hace falta que sea perfecta desde el día uno; hace falta que evite optimizar lo que se mide por comodidad.

Criterios de no construir

Una cultura sana de producto no solo sabe justificar por qué construir. Sabe justificar por qué no.

El criterio de no construir debe estar escrito antes del piloto. Si lo escribimos después, será muy fácil mover la portería para salvar una idea que ya nos gusta.

Ejemplo defendido: no pilotar el cierre automático

Volvamos al caso de matrícula. En el kit del capítulo aparece una candidata llamada auto_close_request: una tool que cerraría solicitudes automáticamente cuando el sistema detecta un caso simple.

Sobre el papel seduce. Tiene valor esperado alto y margen útil aparente. Pero una decisión de producto no puede quedarse en “ahorra tiempo”. En los datos del kit, esta candidata falla en éxito mínimo, groundedness, abstención, recuperación UX y evidencias obligatorias. También queda por debajo en cobertura de trazas y preparación operativa.

La decisión defendible sería:

Esto no es una derrota del producto. Es una decisión madura. El equipo conserva el valor de la idea, pero baja el nivel de autonomía hasta que la evidencia acompañe. En vez de “la IA cierra”, la versión razonable sería: “la IA propone cierre, muestra evidencia, explica límites y una persona confirma”.

Plan de piloto: publicar poco para aprender bien

Un piloto no es una versión pequeña de producción. Es un experimento operacional con alcance, duración, población, métricas y condiciones de parada. Si no escribimos esas condiciones antes, el piloto se convierte en una demo larga: genera anécdotas, pero no una decisión.

Para el caso matricula_rag_assistant, un plan defendible podría ser:

La regla de publicación debería poder escribirse como contrato:

Y las responsabilidades deberían quedar claras:

La frase “lo probamos con usuarios” se queda corta. Una versión de ingeniería sería: “lo probamos con 200 solicitudes, sin acciones automáticas, con trazas obligatorias, umbrales publicados, revisión semanal y retirada si falla calidad, coste o recuperación”. Esa diferencia cambia la conversación.

Árbol rápido de decisión

flowchart TD
  P["¿La tarea está definida sin nombrar IA?"] -->|no| STOP1["No construir todavía<br/>redactar tarea y usuario"]
  P -->|sí| B["¿Existe baseline sin IA?"]
  B -->|no| STOP2["No construir todavía<br/>crear alternativa comparable"]
  B -->|sí| V["¿La IA mejora una métrica de valor?"]
  V -->|no| STOP3["No usar IA<br/>mantener baseline"]
  V -->|sí| G["¿Pasan calidad, coste, UX y operación?"]
  G -->|no| COND["Piloto condicionado<br/>cerrar huecos y repetir gate"]
  G -->|sí| E["¿Hay evidencias y política de retorno?"]
  E -->|no| COND
  E -->|sí| PILOT["Piloto limitado<br/>alcance, métricas y revisión"]

  classDef stop fill:#f2f2f2,stroke:#111,stroke-dasharray:5 4,color:#111;
  classDef go fill:#111,stroke:#111,color:#fff;
  class STOP1,STOP2,STOP3,COND stop;
  class PILOT go;

Este árbol no sustituye al análisis. Sirve para ordenar una conversación que, de otro modo, se dispersa enseguida entre modelos, demos y deseos.

Anatomía de una decisión de producto con IA

Manos a la obra

Vamos a usar el kit real del facsímil 11 para puntuar funciones candidatas. El entregable no es una presentación: es una decisión de producto que puede revisar ingeniería.

Ruta:

kit/

Ejecuta:

# Descomprime el ZIP del capítulo y ejecuta estos comandos dentro de esa carpeta
python3 ops/score_product_readiness.py --write
python3 -m json.tool output/product_readiness_report.json
cat output/product_release_decision.md
cat output/metric_tree.md
cat output/unit_economics.csv
cp templates/ai_product_decision.md output/nota_de_decision.md

El kit compara tres candidatas:

La gracia del ejercicio es que una candidata puede tener margen económico aparente y aun así no pasar. Por ejemplo, cerrar solicitudes automáticamente puede ahorrar tiempo, pero si falla abstención, privacidad, UX o operación, no merece piloto. El producto no se decide por promesa; se decide por evidencia.

Qué deberías mirar

Cómo adaptarlo a tu proyecto

Cambia data/feature_candidates.csv con tus candidatas. Mantén una fila para la alternativa sin IA o descríbela claramente en baseline. Después ajusta contracts/product_ai_release_policy.json con tus umbrales. Si usas palabras normativas como MUST, SHOULD o MAY, RFC 2119 es la referencia clásica para indicar niveles de requisito en documentos técnicos.⁸

Una entrega útil para clase o equipo debería contener:

product-release-review/
  product_readiness_report.json
  product_release_decision.md
  metric_tree.md
  unit_economics.csv
  nota_de_decision.md

nota_de_decision.md debe responder en castellano claro:

1. Qué función merece piloto.
2. Qué alternativa sin IA compite.
3. Qué métrica norte usarías.
4. Qué guardrail bloquearía la publicación.
5. Qué análisis de sensibilidad cambia la decisión.
6. Qué plan de piloto usarías.
7. Qué condición te haría retirar la función.

La plantilla del kit no está para rellenarla mecánicamente. Está para obligarte a escribir una decisión que otra persona pueda discutir. Si no puedes completar una sección, eso no es un fallo de redacción: es una señal de producto.

Cómo encaja todo

Este mapa responde a tres preguntas: qué hereda este capítulo, qué decisión enseña y dónde se reutiliza. La idea central es que producto no vive después de la ingeniería: define qué ingeniería merece existir.

flowchart TD
  subgraph prev["Lo que ya traemos"]
    F04["F04 · Intervención correcta<br/>prompt · RAG · tool · ajuste"]:::external
    F06["F06 · Operación<br/>contratos · SLO · gates · runbooks"]:::external
    F07["F07 · Evaluación<br/>métricas que permiten decidir"]:::external
    F08["F08 · Datos<br/>slices · experimentos · causalidad"]:::external
    F09["F09 · Gobernanza<br/>riesgo · privacidad · evidencias"]:::external
    F10["F10 · Refuerzo<br/>políticas · recompensa · consecuencias"]:::external
  end

  subgraph now["Capítulo 11.01 · Producto con IA"]
    P["problema de usuario"]:::chapter
    B["baseline sin IA"]:::chapter
    I["intervención mínima suficiente"]:::chapter
    M["métrica norte + guardrails"]:::chapter
    E["unidad económica por tarea"]:::chapter
    S["sensibilidad<br/>umbrales que rompen la cuenta"]:::chapter
    R["release decision"]:::decision
  end

  subgraph next["Lo que prepara"]
    UX["11.02 · UX<br/>control, confianza y recuperación"]:::future
    LAB["11.03 · laboratorio final<br/>paquete de producto"]:::future
    VIDA["producto vivo<br/>medir, revisar, retirar"]:::future
  end

  F04 -->|"comparar intervención"| B
  F06 -->|"definir operación"| M
  F07 -->|"medir calidad"| M
  F08 -->|"leer slices"| E
  F09 -->|"exigir evidencias"| R
  F10 -->|"pensar consecuencias"| R
  P -->|"se compara con"| B
  B -->|"elige"| I
  I -->|"se evalúa con"| M
  M -->|"alimenta"| E
  E -->|"se tensiona con"| S
  S -->|"condiciona"| R
  R -->|"diseña experiencia"| UX
  R -->|"se entrega como"| LAB
  LAB -->|"se convierte en"| VIDA

  classDef external fill:#f2f2f2,stroke:#111,stroke-dasharray:5 4,color:#111;
  classDef chapter fill:#fff,stroke:#111,color:#111;
  classDef decision fill:#111,stroke:#111,color:#fff;
  classDef future fill:#f7f7f7,stroke:#111,color:#111;

Vocabulario aprendido

Dónde solía tropezar yo

Antes de pasar página

• ¿Puedes explicar el problema sin nombrar IA?
• ¿Has escrito una alternativa sin IA que compita de verdad?
• ¿Tu métrica norte mide valor o solo uso?
• ¿Has escrito al menos una antimétrica que no quieres optimizar?
• ¿Qué guardrails evitarían optimizar una métrica equivocada?
• ¿Sabes cuánto cuesta una tarea útil completa?
• ¿Puedes separar coste por llamada, coste por tarea útil y coste de cola?
• ¿Has calculado valor esperado por slice?
• ¿Sabes qué variable rompe antes la unidad económica?
• ¿Has escrito duración, población y criterios de parada del piloto?
• ¿Quién revisa cada guardrail y quién decide si se continúa?
• ¿Tienes un criterio explícito para parar, no publicar o retirar la función?
• ¿Puedes conectar la decisión con evaluación, operación, UX y gobernanza?

Para saber más

• Amershi, S., Weld, D., Vorvoreanu, M., Fourney, A., Nushi, B., Collisson, P., Suh, J., Iqbal, S., Bennett, P. N., Inkpen, K., Teevan, J., Kikin-Gil, R., & Horvitz, E. (2019). Guidelines for human-AI interaction. Proceedings of the 2019 CHI Conference on Human Factors in Computing Systems, 1-13. https://doi.org/10.1145/3290605.3300233
• Bradner, S. (1997). Key words for use in RFCs to indicate requirement levels. RFC 2119. https://www.rfc-editor.org/rfc/rfc2119
• Goodhart, C. A. E. (1975). Problems of monetary management: The U.K. experience. En Papers in Monetary Economics. Reserve Bank of Australia. https://www.rba.gov.au/publications/confs/1975/
• Google PAIR. (2026). People + AI Guidebook. https://pair.withgoogle.com/guidebook/
• Gupta, S., Ulanova, L., Bhardwaj, S., Dmitriev, P., Raff, P., & Fabijan, A. (2018). The anatomy of a large-scale experimentation platform. 2018 IEEE International Conference on Software Architecture, 1-109. https://doi.org/10.1109/ICSA.2018.00009
• International Organization for Standardization. (2019). ISO 9241-210:2019. Ergonomics of human-system interaction -- Human-centred design for interactive systems. https://www.iso.org/standard/77520.html
• Kohavi, R., Longbotham, R., Sommerfield, D., & Henne, R. M. (2009). Controlled experiments on the web: Survey and practical guide. Data Mining and Knowledge Discovery, 18(1), 140-181. https://doi.org/10.1007/s10618-008-0114-1
• Microsoft. (2026). Human-AI eXperience Toolkit. https://www.microsoft.com/en-us/haxtoolkit/
• National Institute of Standards and Technology. (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). https://doi.org/10.6028/NIST.AI.100-1

En resumen

Capítulo 02: UX de IA: control, confianza, recuperación y entrega

Una interfaz que cambia de humor no es una interfaz

La UX de un sistema de IA no empieza en el color del botón ni termina en una caja de chat. Empieza en una pregunta más concreta: cuando el sistema no está seguro, cuando tarda, cuando cita mal, cuando necesita permiso, cuando no tiene evidencia o cuando produce una salida incompleta, ¿qué ve la persona y qué puede hacer?

Un software clásico puede fallar, claro. Pero suele fallar dentro de estados más delimitados: error de red, campo obligatorio, permiso insuficiente, validación rota. Un sistema con IA introduce otro tipo de variabilidad: puede responder distinto ante entradas parecidas, puede sonar seguro sin estarlo, puede pedir una herramienta, puede abstenerse, puede necesitar revisión o puede mezclar evidencia correcta con una conclusión débil.

La UX de IA es la disciplina de hacer visible esa variabilidad sin convertir la pantalla en una tesis doctoral.

Qué no es confianza

Confianza no significa que el usuario “crea” al sistema. Tampoco significa decorar la respuesta con una puntuación misteriosa. Y no significa enseñar todos los detalles internos como si la transparencia total fuera automáticamente útil.

Una experiencia confiable permite calibrar expectativas. La persona entiende qué puede pedir, por qué la respuesta está sustentada, qué límites tiene, qué datos se usaron, qué acción se propone y cómo corregirla. Si el sistema debe decir “no lo sé”, lo dice sin castigar al usuario. Si necesita permisos, los pide con objeto, alcance y efecto. Si hay una acción irreversible, no la ejecuta como si fuera una sugerencia de texto.

Amershi y coautores sintetizaron guías para interacción humano-IA que cubren etapas como mostrar qué puede hacer el sistema, explicar durante la interacción, permitir corrección, apoyar aprendizaje gradual y ayudar a recuperarse de errores.¹ Microsoft HAX convierte esas guías en herramientas de diseño como workbook, patrones y playbook para planificar comportamientos de sistemas de IA.² Google People + AI Guidebook propone diseñar alrededor de necesidades humanas, datos, modelos mentales, feedback, control y evaluación.³

La lectura común es clara: una buena UX de IA no intenta que la IA parezca humana. Intenta que la persona pueda trabajar mejor con un sistema probabilístico.

Estados mínimos de una experiencia con IA

Una interfaz de IA seria debe diseñar estados, no solo respuestas.

La UX se vuelve ingeniería cuando cada estado tiene entrada, salida, evento de traza, copy, acción permitida y criterio de aceptación.

La UX como máquina de estados

Una forma práctica de diseñar UX de IA es tratar la interfaz como una máquina de estados. No porque todo tenga que ser rígido, sino porque cada estado obliga a responder preguntas verificables: qué sabe el sistema, qué no sabe, qué está intentando, qué puede hacer la persona y qué evento quedará registrado.

Un estado mínimo debería declararse así:

En forma de contrato, podría verse así:

state_id: insufficient_evidence
entry_condition: "retrieval devuelve menos de dos fuentes válidas o la fuente principal no cubre la pregunta"
visible_copy: "No tengo evidencia suficiente para responder con seguridad."
available_actions:
  - aportar_documento
  - cambiar_pregunta
  - escalar_revision
blocked_actions:
  - enviar_respuesta_final
  - cerrar_solicitud
trace_event:
  name: ux.insufficient_evidence_shown
  required_fields:
    - trace_id
    - user_role
    - missing_evidence_reason
    - retrieval_run_id
acceptance_criteria:
  - "la persona entiende qué falta"
  - "existe camino manual"
  - "la respuesta no se maquilla como certeza"

Esta especificación parece pequeña, pero cambia el trabajo. Ya no estamos escribiendo “hacer UX de error”. Estamos definiendo un comportamiento observable, revisable y testeable. Si mañana cambia el modelo, el contrato sigue diciendo qué debe pasar cuando la evidencia no basta.

stateDiagram-v2
  [*] --> EntradaValida
  EntradaValida --> RecuperandoEvidencia: permisos de lectura OK
  EntradaValida --> PedirPermiso: falta permiso
  PedirPermiso --> RecuperandoEvidencia: permiso aprobado
  PedirPermiso --> FlujoManual: permiso rechazado
  RecuperandoEvidencia --> EvidenciaSuficiente: fuentes válidas
  RecuperandoEvidencia --> EvidenciaInsuficiente: fuentes incompletas
  RecuperandoEvidencia --> FlujoManual: timeout o sistema externo no disponible
  EvidenciaSuficiente --> RespuestaRevisable: generar salida con citas
  EvidenciaInsuficiente --> Recuperacion: pedir dato, documento o revisión
  RespuestaRevisable --> Aprobacion: hay acción externa
  RespuestaRevisable --> GuardarBorrador: solo redacta texto
  Aprobacion --> EjecutarAccion: payload revisado
  Aprobacion --> EditarPayload: cambios necesarios
  EditarPayload --> Aprobacion
  EjecutarAccion --> [*]
  GuardarBorrador --> [*]
  Recuperacion --> [*]
  FlujoManual --> [*]

Fíjate en la separación: redactar, aprobar y ejecutar no son el mismo estado. En sistemas con tools, esa separación es una línea de seguridad operativa y también una línea de UX: la persona debe saber cuándo está leyendo una sugerencia y cuándo está a punto de cambiar un sistema real.

Calibrar confianza con números y comportamiento

La confianza se calibra con dos piezas: comportamiento del sistema y diseño visible.

Podemos modelar riesgo de experiencia de forma simple:

Con estos valores:

El número no es una verdad física. Es una herramienta de conversación. Si aumenta la recuperación, baja el riesgo. Si aumenta el impacto, necesitas más control antes de publicar. Si no puedes estimar $P(error)$, no tienes UX lista: tienes una pantalla esperando datos.

Diseño de recuperación

La recuperación debe estar diseñada antes de enseñar la función. En sistemas de IA, recuperar no es solo “volver atrás”. Puede significar:

El capítulo 05 del facsímil de agentes ya trabajó permisos; el facsímil 09 trabajó privacidad y evidencias. Aquí lo unimos desde el punto de vista de la persona: no basta con que haya un control en backend; tiene que existir un camino comprensible para usarlo.

Tarjeta de aprobación: cuando la IA propone una acción

La tarjeta de aprobación es una pieza central en productos con IA que pueden actuar. Su objetivo no es poner un botón de “aceptar”. Su objetivo es convertir una acción en una decisión informada.

Una tarjeta defendible debe responder:

Ejemplo:

{
  "approval_card": {
    "action": "enviar_respuesta_revisada",
    "system": "gestor_solicitudes",
    "object_id": "solicitud-2026-1042",
    "reason": "la normativa recuperada cubre la pregunta y el expediente contiene justificante pendiente de revisión",
    "evidence": [
      {"source": "normativa_matricula_2026", "section": "pagos_pendientes"},
      {"source": "expediente", "field": "justificante_subido"}
    ],
    "editable_payload": {
      "response_text": "Antes de cerrar la solicitud, revise el justificante subido el 03/06.",
      "next_status": "revision_humana"
    },
    "blocked_without": ["role:coordinacion_academica", "trace_id", "evidence_visible"],
    "recovery": ["editar_texto", "pedir_mas_evidencia", "escalar_revision", "cancelar"]
  }
}

Esta tarjeta obliga a ingeniería, producto y UX a ponerse de acuerdo. Si no sabes rellenar system, object_id, evidence, editable_payload o blocked_without, la acción todavía no está lista para vivir en una interfaz.

Copy técnico: decir lo justo, no sonar seguro de más

El texto de la interfaz es parte del sistema. En IA, una frase puede calibrar o descalibrar. “He encontrado la respuesta” no significa lo mismo que “He encontrado dos fuentes que parecen sostener esta respuesta”. “No puedo ayudarte” no significa lo mismo que “Falta una fuente obligatoria para responder sin inventar”.

El patrón es sencillo: verbo concreto, objeto concreto, límite concreto y siguiente paso concreto. En productos profesionales, el copy no debe tranquilizar artificialmente. Debe permitir decidir.

Accesibilidad y carga cognitiva

Diseñar UX de IA también implica diseñar para personas con distintos niveles de atención, contexto, cansancio, visión, experiencia técnica o familiaridad con el sistema. WCAG 2.2 ofrece criterios de accesibilidad para contenido web, interacción por teclado, contraste, foco visible, identificación de errores y ayuda en entradas.⁴

En IA hay una capa adicional: carga cognitiva por incertidumbre. La persona no solo interpreta una interfaz; interpreta un sistema que puede equivocarse con buena gramática. Por eso conviene aplicar reglas muy concretas:

La accesibilidad no es un anexo. Si una persona no puede percibir, navegar, entender o corregir la salida, el sistema no está listo.

Medir UX en IA

El System Usability Scale (SUS), presentado por Brooke, es una escala breve y muy extendida para medir usabilidad percibida.⁵ Estudios posteriores lo han usado y analizado en contextos comerciales y de investigación.⁶

Pero en IA necesitamos combinar SUS con métricas propias:

Una UX buena no maximiza confianza. Maximiza confianza merecida.

Protocolo de medición para una revisión UX de IA

Una revisión útil no se limita a “cinco personas lo probaron”. Debe tener escenarios, tareas, observaciones y criterios de salida.

Ejemplo de matriz:

El kit del capítulo usa exactamente esta idea: cada fila de ux_review_sessions.csv representa un escenario, y el script comprueba si aparecen estados, evidencia, límites, separación de acción, recuperación, accesibilidad, trazas y fallback manual.

Anatomía de una pantalla de IA que se puede defender

Manos a la obra

Convierte una función de IA en un contrato UX:

kit/templates/ux_contract.md
ux_contract.md
states.csv
recovery_paths.csv
copy_review.md
ux_gate.json

Incluye:

En este repositorio tienes una plantilla en:

kit/templates/ux_contract.md

Úsala para escribir el contrato de una función concreta. Después ejecuta:

# Descomprime el ZIP del capítulo y ejecuta estos comandos dentro de esa carpeta
python3 ops/review_ux_flows.py --write
cat output/ux_decision.md
cat output/ux_release_gate.json

El script no decide si la pantalla es bonita. Decide si la experiencia tiene lo mínimo para publicarse: estados visibles, evidencia, límites, separación entre sugerencia y acción, recuperación, accesibilidad, trazas y fallback manual. Si el gate queda en review, no es un suspenso: es una lista de trabajo antes del piloto.

Cómo encaja todo

Este mapa conecta UX con producto, RAG, agentes, evaluación y privacidad. La UX no es una capa final: es donde las decisiones técnicas se vuelven visibles para quien usa el sistema.

flowchart TD
  subgraph prev["Lo que ya traemos"]
    C01["11.01 · AI-fit<br/>valor, coste y piloto"]:::external
    RAG["04.09 · RAG<br/>evidencia, citas y abstención"]:::external
    AG["05.08 · Agentes<br/>permisos y autonomía"]:::external
    CAL["07.05 · Calibración<br/>incertidumbre y umbrales"]:::external
    GOV["09.02 · Privacidad<br/>datos, memoria y trazas"]:::external
  end

  subgraph now["Capítulo 11.02 · UX de IA"]
    ST["máquina de estados<br/>qué está ocurriendo"]:::chapter
    EV["evidencia y límites<br/>por qué se sostiene"]:::chapter
    AP["tarjeta de aprobación<br/>qué acción se ejecutaría"]:::chapter
    RC["recuperación<br/>cómo corregir o escalar"]:::chapter
    MX["medición UX<br/>éxito, comprensión y control"]:::chapter
  end

  subgraph next["Lo que prepara"]
    LAB["11.03 · laboratorio final<br/>paquete de producto"]:::future
    REL["release defendible<br/>producto + UX + operación"]:::future
    VIDA["producto vivo<br/>revisar, retirar, mejorar"]:::future
  end

  C01 -->|"define alcance"| ST
  RAG -->|"aporta fuentes"| EV
  AG -->|"separa sugerir y actuar"| AP
  CAL -->|"calibra límites"| RC
  GOV -->|"exige trazas y permisos"| AP
  ST -->|"ordena pantalla"| EV
  EV -->|"habilita decisión"| AP
  AP -->|"si no procede"| RC
  RC -->|"se comprueba con"| MX
  MX -->|"alimenta"| LAB
  LAB -->|"decide"| REL
  REL -->|"entra en ciclo de"| VIDA

  classDef external fill:#f2f2f2,stroke:#111,stroke-dasharray:5 4,color:#111;
  classDef chapter fill:#fff,stroke:#111,color:#111;
  classDef future fill:#111,stroke:#111,color:#fff;

Dónde solía tropezar yo

Vocabulario aprendido

Antes de pasar página

• ¿Puedes enumerar los estados de tu función de IA?
• ¿La persona ve qué evidencia sostiene la respuesta?
• ¿Hay un camino claro cuando la respuesta es insuficiente?
• ¿Las acciones externas están separadas de las sugerencias?
• ¿Tienes una tarjeta de aprobación con acción, evidencia, payload y recuperación?
• ¿El copy distingue entre certeza, evidencia parcial y abstención?
• ¿Mides recuperación, no solo satisfacción?
• ¿El usuario conserva control cuando el sistema duda?

Para saber más

• Amershi, S., Weld, D., Vorvoreanu, M., Fourney, A., Nushi, B., Collisson, P., Suh, J., Iqbal, S., Bennett, P. N., Inkpen, K., Teevan, J., Kikin-Gil, R., & Horvitz, E. (2019). Guidelines for human-AI interaction. Proceedings of the 2019 CHI Conference on Human Factors in Computing Systems, 1-13. https://doi.org/10.1145/3290605.3300233
• Brooke, J. (1996). SUS: A quick and dirty usability scale. En P. W. Jordan, B. Thomas, B. A. Weerdmeester, & I. L. McClelland (Eds.), Usability Evaluation in Industry (pp. 189-194). Taylor & Francis.
• Google PAIR. (2026). People + AI Guidebook. https://pair.withgoogle.com/guidebook/
• Grier, R. A., Bangor, A., Kortum, P., & Peres, S. C. (2013). The System Usability Scale: beyond standard usability testing. Proceedings of the Human Factors and Ergonomics Society Annual Meeting, 57(1), 187-191. https://doi.org/10.1177/1541931213571042
• International Organization for Standardization. (2019). ISO 9241-210:2019. Ergonomics of human-system interaction -- Human-centred design for interactive systems. https://www.iso.org/standard/77520.html
• Microsoft. (2026). Human-AI eXperience Toolkit. https://www.microsoft.com/en-us/haxtoolkit/
• National Institute of Standards and Technology. (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). https://doi.org/10.6028/NIST.AI.100-1
• World Wide Web Consortium. (2023). Web Content Accessibility Guidelines (WCAG) 2.2. https://www.w3.org/TR/WCAG22/

En resumen

Capítulo 03: Cierre del libro y laboratorio de producto

Qué queda cuando quitamos la novedad

Llegamos al final del volumen. Si este libro ha funcionado, la IA debería parecerte menos inexplicable y más interesante. Menos “un modelo responde” y más “un sistema con datos, contratos, herramientas, evaluación, operación, experiencia y consecuencias”. Esa diferencia no es estética: cambia cómo diseñas, cómo presupuestas, cómo publicas y cómo paras una función cuando deja de sostenerse.

El objetivo no era que memorizaras nombres. Era construir criterio. Saber cuándo una neurona artificial es una suma con activación. Saber que un token no es una palabra. Saber que una búsqueda puede necesitar heurísticas, que una herramienta necesita contrato, que un agente necesita límites, que un dataset condiciona todo, que una evaluación decide algo, que una recompensa puede torcer una conducta y que una interfaz debe ayudar a la persona a trabajar con incertidumbre.

Este cierre convierte ese criterio en una entrega final: un paquete de producto para decidir si una función de IA puede pasar a piloto. No es un ejercicio de estilo. Es una simulación pequeña de una conversación real: producto quiere publicar, ingeniería pide evidencia, datos preguntan por calidad, operación pide rollback, gobernanza pide trazas y la persona usuaria necesita una experiencia que no la deje sola ante una respuesta incierta.

La pregunta final del libro no es “¿qué modelo usarías?”. La pregunta final es más incómoda y más útil:

¿Publicarías esta función, en este alcance, con estas métricas, estos costes, esta UX y estas evidencias?

Si puedes responder sin esconderte en frases generales, has empezado a pensar como alguien que construye IA de verdad.

Lo que hemos construido en el libro

La lectura profesional de esta tabla no es “hemos visto muchas cosas”. Es esta: cada facsímil te permite hacer una pregunta que evita publicar por entusiasmo.

Fecha de corte y fuentes consultadas

Fecha de corte: 7 de junio de 2026.

Este cierre usa marcos de diseño centrado en personas, interacción humano-IA, evaluación de producto y gestión de riesgos: ISO 9241-210, guías de Amershi et al., Microsoft HAX, People + AI Guidebook de Google, NIST AI RMF y literatura sobre experimentación controlada.¹²³⁴⁵⁶

También toma una lección de las plataformas de experimentación: una decisión de producto no se sostiene solo con una métrica final; necesita instrumentación, calidad de datos, asignación, análisis y comunicación de resultados.⁷

La idea común es exigente y útil: una función de IA debe diseñarse, medirse, operarse y revisarse como sistema interactivo, no como una respuesta aislada.

Cómo encaja todo

Este mapa no intenta resumir los once facsímiles capítulo a capítulo. Está construido como un mapa de release: qué hereda el producto, qué decisiones exige y qué evidencias deja. Se lee de izquierda a derecha: primero entendemos el mecanismo, después construimos el sistema, luego lo medimos y gobernamos, y finalmente decidimos si merece vivir como producto.

flowchart LR
  subgraph know["Entender el mecanismo"]
    F01["F01 · Cimientos<br/>tokens · error · inferencia"]:::external
    F02["F02 · IA clásica<br/>búsqueda · restricciones · planificación"]:::external
    F03["F03 · Arquitecturas<br/>Transformer · MoE · serving"]:::external
  end

  subgraph build["Construir el sistema"]
    F04["F04 · Herramientas<br/>API · RAG · embeddings · SQL"]:::external
    F05["F05 · Agentes<br/>tools · memoria · permisos"]:::external
    F06["F06 · Operación<br/>SLO · trazas · gates · runbooks"]:::external
  end

  subgraph proof["Probar y limitar"]
    F07["F07 · Evaluación<br/>métricas · calibración · gates"]:::external
    F08["F08 · Datos<br/>linaje · calidad · slices · DataOps"]:::external
    F09["F09 · Gobernanza<br/>privacidad · evidencias · AI-BOM"]:::external
    F10["F10 · Refuerzo<br/>política · recompensa · consecuencias"]:::external
  end

  subgraph product["Facsímil 11 · Producto y UX"]
    C01["11.01 · AI-fit<br/>problema · métrica · coste · riesgo"]:::chapter
    C02["11.02 · UX de IA<br/>control · confianza · recuperación"]:::chapter
    C03["11.03 · Cierre<br/>paquete final · laboratorio"]:::lab
  end

  subgraph packet["Paquete final"]
    P1["nota_de_decision.md<br/>PRD/ADR de IA"]:::artifact
    P2["eval + data + cost<br/>métricas y sensibilidad"]:::artifact
    P3["ux_contract.md<br/>estados, aprobación y recuperación"]:::artifact
    P4["release_gate.json<br/>decisión ejecutable"]:::artifact
    OUT["final_product_packet.md<br/>decisión defendible"]:::decision
  end

  F01 -->|"entender bases"| F04
  F02 -->|"modelar decisión"| F05
  F03 -->|"elegir mecanismo"| F04
  F04 -->|"construir intervención"| F06
  F05 -->|"dar capacidad con límites"| F06
  F06 -->|"hacer operable"| F07
  F08 -->|"dar datos y slices"| F07
  F09 -->|"exigir evidencia"| F06
  F10 -->|"leer conducta inducida"| C01
  F07 -->|"decidir con pruebas"| C01
  F08 -->|"validar materia prima"| P2
  F09 -->|"preparar expediente"| P4
  C01 -->|"definir si merece existir"| P1
  C02 -->|"hacerlo usable y corregible"| P3
  C03 -->|"integrar entrega"| OUT
  P1 --> OUT
  P2 --> OUT
  P3 --> OUT
  P4 --> OUT

  classDef external fill:#f2f2f2,stroke:#111,stroke-dasharray:5 4,color:#111;
  classDef chapter fill:#fff,stroke:#111,color:#111;
  classDef lab fill:#111,stroke:#111,color:#fff;
  classDef artifact fill:#fff,stroke:#111,stroke-width:1.5px,color:#111;
  classDef decision fill:#fff,stroke:#111,stroke-width:2px,color:#111;

El mapa final responde a tres preguntas. Qué hereda este cierre: fundamentos, herramientas, operación, evaluación, datos, gobernanza y refuerzo. Qué enseña: convertir todo eso en decisión de producto. Dónde se reutiliza después: en cualquier proyecto donde haya que defender una función de IA ante usuarios, ingeniería, negocio o revisión.

Anatomía del paquete final

El paquete final no es una carpeta de informes sueltos. Es una cadena de decisión. Cada pieza responde a una pregunta distinta y ninguna sustituye a las demás.

Tres niveles de cierre

Hay tres formas de cerrar un proyecto de IA. Solo una es suficiente para publicar con tranquilidad.

Este capítulo trabaja el tercer nivel. No porque todo deba ser perfecto, sino porque un piloto serio no es “lo ponemos y ya vemos”. Un piloto serio es una hipótesis acotada: creemos que esta función mejora esta tarea, en esta población, durante esta ventana, bajo estas condiciones, y sabremos retirarla si los datos contradicen la hipótesis.

Qué debe contener una entrega defendible

Una entrega final no debería depender de una explicación oral. Si el equipo no está presente, otra persona debe poder abrir la carpeta y entender qué se propone, qué se midió, qué falta y qué decisión se toma.

La carpeta buena no es la que tiene más archivos. Es la que permite tomar una decisión sin inventar contexto.

Un buen paquete final también separa tres tipos de lenguaje:

Si una entrega solo habla uno de esos idiomas, la discusión se rompe. Producto puede aprobar algo que ingeniería no puede operar. Ingeniería puede construir algo que nadie necesita. Revisión puede pedir controles que no están conectados con el flujo real. El paquete final existe para que esas conversaciones se encuentren en los mismos artefactos.

Laboratorio

kit/

# Descomprime el ZIP del capítulo y ejecuta estos comandos dentro de esa carpeta
python3 ops/score_product_readiness.py --write
python3 ops/review_ux_flows.py --write
cp templates/ai_product_decision.md output/nota_de_decision.md
cp templates/ux_contract.md output/ux_contract.md
python3 ops/check_student_submission.py --submission-dir solutions/reference --write --fail-on-missing

product-release-review/
  product_readiness_report.json
  product_release_decision.md
  metric_tree.md
  unit_economics.csv
  nota_de_decision.md
  final_product_packet.md

ux-release-review/
  ux_review_report.json
  ux_release_gate.json
  ux_contract.md
  ux_decision.md
  final_product_packet.md