Glosario de Producto y Gestión de IA

Los términos que aparecen una y otra vez en el Curso de Producto y Gestión de IA, en la Metodología de casos de uso de IA y en cualquier conversación sobre decidir, financiar y liderar una iniciativa de IA sin escribir una línea de código. Como todo glosario de la academia, crece con cada bloque nuevo.

Enmarcar el problema

Caso de uso (use case) — La descripción concreta de quién hace qué, en qué momento y con qué resultado, que una iniciativa de IA pretende cambiar. No es una tecnología (“usemos un LLM”) sino un problema con dueño, frecuencia y costo actual. Se desarrolla en ¿Es un problema de IA?.

Problema vs solución — La distinción entre el dolor que se quiere resolver y el mecanismo elegido para resolverlo. Confundirlos es el error de origen: se compromete la solución (“un chatbot”) antes de haber entendido el problema.

Job-to-be-done (trabajo por hacer, JTBD) — El marco que describe qué “contrata” un usuario para lograr, no qué funciones pide. Enfoca el diseño en el progreso que la persona busca, y evita construir una función que nadie usa.

Deseable / viable / factible (desirable / viable / feasible) — Las tres condiciones que un producto debe cumplir a la vez: que alguien lo quiera, que tenga sentido de negocio y que se pueda construir. La IA suele fallar en la tercera, y por eso la factibilidad se evalúa temprano en Viabilidad, datos y factibilidad.

Descubrimiento (discovery) — La fase previa a construir, dedicada a entender el problema, el usuario y el valor antes de comprometer ingeniería. Recorta el riesgo de invertir meses en algo que nadie necesitaba.

Solución en busca de problema (solution looking for a problem) — El antipatrón de partir de la tecnología disponible (“tenemos un modelo, ¿dónde lo metemos?”) en vez del dolor del usuario. Es una de las causas más comunes de pilotos de IA que no llegan a producción.

El caso de negocio

Business case (caso de negocio) — El documento que justifica la inversión: qué problema resuelve, cuánto valor genera, cuánto cuesta y en qué plazo se recupera. Convierte una intuición en una decisión defendible. Se desarrolla en Del caso de uso al business case.

ROI (retorno de la inversión, return on investment) — La relación entre lo que se gana y lo que se invierte: ROI = (beneficio − costo) / costo. Un ROI del 150% significa que por cada peso invertido vuelven 2,5. Es la cifra que abre o cierra la conversación con finanzas.

Costo total de propiedad (TCO, total cost of ownership) — Todo lo que cuesta un sistema durante su vida, no solo construirlo: inferencia, datos, personas, mantenimiento, cumplimiento y la deuda de tenerlo funcionando. Un caso de negocio que solo mira el costo de desarrollo subestima el TCO por un factor grande.

Costo de oportunidad (opportunity cost) — El valor de la mejor alternativa a la que se renuncia al elegir un proyecto. El equipo que construye X no está construyendo Y: ese Y perdido es parte del costo real de X.

Valor cuantificado (quantified value) — Traducir el beneficio a una cifra defendible: horas ahorradas por su costo, errores evitados por lo que cuestan, ingresos incrementales. “Mejora la experiencia” no es valor cuantificado; “reduce 4 minutos por ticket sobre 200.000 tickets al año” sí.

One-pager (una página) — El resumen de una sola hoja del caso de negocio: problema, propuesta, valor, costo y decisión pedida. Si no cabe en una página, todavía no está claro.

Umbral no-go (no-go threshold) — La condición declarada de antemano que, si no se cumple, mata el proyecto. Se escribe y se firma antes de construir: después de invertir, el costo hundido negocia todo umbral a la baja.

Viabilidad

Factibilidad técnica (technical feasibility) — Si el sistema se puede construir con los modelos, datos e infraestructura disponibles a un costo razonable. Es la dimensión donde más iniciativas de IA se estrellan. Se desarrolla en Viabilidad, datos y factibilidad.

Calidad de datos (data quality) — Si los datos existen, son correctos, están completos, actualizados y se pueden usar legalmente. Ningún modelo compensa datos malos: es el techo real de casi todo proyecto de IA.

Etiquetado (labeling / annotation) — El trabajo de anotar ejemplos con la respuesta correcta para entrenar o evaluar. Suele ser el cuello de botella oculto de un proyecto: caro, lento y difícil de mantener consistente.

Spike (exploración acotada) — Un experimento técnico con tiempo limitado (unos días) para reducir una incertidumbre concreta antes de comprometerse. Compra información sobre lo que no se sabe todavía.

Prueba de concepto (PoC, proof of concept) — Una versión mínima que demuestra que la idea funciona técnicamente, sin preocuparse por escala ni producción. Responde “¿es posible?”, no “¿está listo?”.

Riesgo más grande primero (riskiest assumption first) — La regla de atacar antes lo que, si falla, tira abajo todo el proyecto. Probar primero lo fácil y dejar lo incierto para el final es cómo se llega tarde y caro a la mala noticia.

Build vs buy

Build vs buy vs API (construir, comprar o consumir) — La decisión de fondo: desarrollar la capacidad en casa, comprar un producto cerrado o consumir un modelo de terceros por API. Cada opción cambia el costo, el control y la velocidad. Se desarrolla en Build vs buy vs API.

Commodity vs diferenciación (commodity vs differentiation) — La distinción entre lo que es igual para todos (una capacidad genérica que cualquiera compra) y lo que te hace único. La regla: comprar el commodity, construir solo lo que diferencia.

Vendor lock-in (dependencia del proveedor) — El costo de quedar atado a un proveedor porque cambiar sería caro o lento. Se mitiga con abstracciones, contratos y una estrategia de salida pensada antes de firmar, no después.

Self-hosting (alojamiento propio) — Correr el modelo en tu propia infraestructura en vez de consumirlo por API. Da control y a veces costo menor a gran volumen, a cambio de asumir la operación, las GPU y el mantenimiento. Ver GPU en producción: costos y decisiones.

Time-to-value (tiempo hasta el valor) — Cuánto tarda la organización en obtener beneficio real, no en terminar de construir. Una API que entrega valor en dos semanas suele ganarle a un desarrollo propio superior que llega en seis meses.

Roadmap

Roadmap por outcomes vs features (hoja de ruta por resultados vs funciones) — Planificar por los resultados que se quieren lograr (reducir el tiempo de respuesta a la mitad) en vez de por la lista de funciones a construir. El roadmap por outcomes sobrevive a que una función concreta no funcione. Se desarrolla en Roadmap de un producto de IA.

PoC purgatory (purgatorio del piloto) — El estado donde una organización acumula pruebas de concepto exitosas que nunca llegan a producción. La demo impresiona, se felicita a todos y nada cambia para el usuario. Es el fracaso más común de los programas de IA.

Piloto (pilot) — Un despliegue real pero limitado a un segmento chico de usuarios, para aprender en condiciones de verdad antes de escalar. A diferencia de una PoC, sí toca a usuarios reales y sí mide valor.

Now / next / later (ahora / siguiente / después) — El formato de roadmap que ordena por horizonte de compromiso en vez de por fechas exactas. Comunica prioridad sin prometer un calendario que la incertidumbre de la IA hará incumplir.

Criterio de salida (exit criteria) — Las condiciones concretas que un piloto debe cumplir para pasar a la siguiente fase o cerrarse. Sin criterio de salida escrito, el piloto se extiende indefinidamente porque nadie sabe cuándo terminó.

Gate go/no-go (compuerta seguir/parar) — El punto de decisión formal entre fases donde se decide continuar, pivotar o matar la iniciativa con datos a la vista. Es lo que convierte el roadmap en una serie de apuestas revisables y no en un compromiso ciego.

Calidad suficiente para lanzar (good enough to ship) — El nivel de calidad a partir del cual el valor de lanzar supera al riesgo de esperar. Perseguir la perfección en un sistema probabilístico es cómo se llega tarde; la clave está en definir el umbral en Métricas y KPI.

Priorización

RICE (Reach, Impact, Confidence, Effort) — El framework de priorización que puntúa cada iniciativa con (Alcance × Impacto × Confianza) / Esfuerzo. Nacido en el equipo de crecimiento de Intercom, obliga a estimar cuánta gente afecta, cuánto mueve la aguja, cuánto lo crees y cuánto cuesta. Se desarrolla en Priorización.

ICE (Impact, Confidence, Ease) — La versión ligera de RICE: impacto por confianza por facilidad, sin el alcance. Más rápida y más subjetiva; sirve para descartar grueso antes de afinar con RICE.

Valor vs esfuerzo (value vs effort) — La matriz de dos ejes que separa las apuestas en victorias rápidas, grandes proyectos, rellenos y trampas. Es la priorización más simple y la puerta de entrada a las demás.

Kano (modelo de Kano) — El modelo que clasifica funciones por su efecto en la satisfacción: básicas (su ausencia enfada, su presencia no suma), de rendimiento (más es mejor, proporcional) y deleite (inesperadas, diferencian). Recuerda arreglar lo básico antes de invertir en lo que “encanta”.

HiPPO (Highest Paid Person’s Opinion) — La decisión tomada por la opinión de quien más gana en la sala, no por la evidencia. Es el enemigo silencioso de toda priorización basada en datos.

Sunk cost (costo hundido) — El dinero ya gastado e irrecuperable, que no debería influir en la decisión de seguir o parar, pero casi siempre lo hace. “Ya invertimos seis meses” es la frase que mantiene vivos proyectos muertos.

Feature factory (fábrica de funciones) — El antipatrón de medir el éxito por cantidad de funciones entregadas en vez de por el valor generado. Produce mucho software y poco impacto.

Valor de la información (value of information) — Cuánto vale reducir una incertidumbre antes de decidir. Justifica invertir en un spike o un piloto: a veces la mejor jugada es pagar por saber más antes de comprometer el presupuesto grande.

Métricas

Métrica de modelo vs de negocio (model metric vs business metric) — La distinción entre lo que mide el modelo (precisión, F1, latencia) y lo que le importa al negocio (ingresos, retención, costo por caso). Un modelo con 95% de precisión que no mueve ninguna métrica de negocio no vale nada. Se desarrolla en Métricas y KPI; la definición de éxito se conecta con Definir el éxito.

North star metric (métrica estrella polar) — La única métrica que mejor captura el valor que el producto entrega al cliente y guía a todo el equipo hacia el mismo norte. No es un KPI financiero: es el indicador del valor entregado del que se derivan los demás.

Árbol de KPI (driver tree) — La jerarquía que descompone la north star metric en las palancas que la mueven, y esas en sub-palancas accionables. Muestra en qué se puede trabajar concretamente para mover el número de arriba.

KPI (indicador clave de desempeño, key performance indicator) — Una métrica elegida porque refleja el progreso hacia un objetivo y alguien es responsable de ella. La palabra “clave” importa: cincuenta KPI no son KPI, son un tablero que nadie mira.

Métrica guardrail (métrica de guardia) — La que no debe empeorar aunque la métrica objetivo suba: costo por tarea, latencia, tasa de error, satisfacción. Existe para que optimizar una cosa no rompa otra en silencio. Comparte definición con el glosario de Evals.

Métrica de vanidad (vanity metric) — La que se ve bien en una diapositiva pero no informa ninguna decisión: número de usuarios registrados, likes, visitas totales. Sube siempre y no dice nada sobre el valor real.

Ciclo offline-online — La idea de que la métrica medida en pruebas controladas (offline) y la medida sobre tráfico real (online) deben conectarse: lo que mejora offline tiene que verse online, o la métrica offline está mintiendo. Se detalla desde el lado de evaluación en el glosario de Evals.

Ficha de métrica (metric spec) — El documento corto que define cada métrica: qué mide, cómo se calcula, con qué datos, quién es el dueño, cuál es el umbral y qué decisión dispara. Evita la métrica huérfana que cada persona interpreta a su manera.

Presupuesto

FinOps (operaciones financieras del cloud) — La disciplina que trae responsabilidad financiera al gasto variable de la nube y la IA, juntando a finanzas, tecnología y negocio para decidir entre velocidad, costo y calidad. Opera en un ciclo de informar, optimizar y operar. Se desarrolla en Presupuesto y FinOps.

Unit economics (economía unitaria) — El costo de entregar una sola unidad de valor: costo por usuario, por transacción, por consulta resuelta. Conecta el gasto agregado en IA con el resultado, y es lo que dice si el producto es sostenible a escala o pierde plata en cada uso.

Costo por tarea (cost per task) — Lo que cuesta resolver un caso completo sumando todas las llamadas al modelo, no una sola. Es la métrica que hace insostenible a un agente que se pasea de más antes de responder.

Model routing (enrutamiento de modelos) — Mandar cada consulta al modelo más barato que la resuelve bien, reservando el modelo caro para lo difícil. Es una de las palancas de costo más grandes: la mayoría de las consultas no necesita el modelo tope.

Caché de prompts (prompt caching) — Reutilizar el resultado o el contexto ya procesado en vez de volver a pagarlo. Cuando la misma instrucción larga se repite en cada llamada, cachearla recorta costo y latencia de forma directa.

Presupuesto y alertas (budgets and alerts) — Límites de gasto declarados con avisos automáticos cuando se acercan. Sin ellos, el costo de un sistema de IA se descubre en la factura de fin de mes, cuando ya es tarde.

Escenarios de costo (cost scenarios) — Proyectar el gasto en volumen bajo, esperado y alto en vez de un solo número. La IA escala con el uso: un costo cómodo en el piloto puede ser ruinoso al éxito.

Equipo

AI PM (product manager de IA) — El responsable de producto de una iniciativa de IA: define el problema, prioriza, mide el valor y traduce entre negocio y equipo técnico. No entrena modelos; decide qué se construye y por qué. Se desarrolla en Equipo y modelo operativo.

Ingeniero de ML (ML engineer) — Quien construye, entrena y ajusta los modelos y su servicio en producción. Es distinto del científico de datos: su foco es que el sistema funcione en producción, no el experimento.

Ingeniero de datos (data engineer) — Quien construye y mantiene las tuberías que llevan datos limpios y confiables al modelo. Suele ser el rol más subestimado y el que más determina si el proyecto funciona.

MLOps (operaciones de ML) — La práctica de desplegar, monitorear y mantener modelos en producción de forma confiable y repetible. Es lo que evita que un modelo bueno se degrade en silencio. Ver ¿Qué es MLOps?.

Experto de dominio (domain expert) — La persona que conoce el problema real: el médico, el analista, el operario. Aporta el criterio que ningún dato tiene y define qué respuesta es de verdad correcta.

Anotador (annotator) — Quien etiqueta los datos y evalúa las salidas contra la rúbrica. La calidad de todo el sistema depende de la consistencia de su trabajo, y por eso el etiquetado se gestiona, no se improvisa.

RACI (Responsible, Accountable, Consulted, Informed) — La matriz que asigna, para cada decisión o entregable, quién lo ejecuta (R), quién responde por él (A, uno solo), a quién se consulta (C) y a quién se informa (I). Elimina la ambigüedad de “yo pensé que lo hacías tú”.

Centro de excelencia (center of excellence, CoE) — El equipo central que fija estándares, herramientas y buenas prácticas de IA para toda la organización. Acelera al resto, con el riesgo de convertirse en cuello de botella si concentra todo el trabajo.

Modelo operativo (operating model) — Cómo se organiza el trabajo de IA en la empresa: centralizado, distribuido o híbrido. Determina quién decide, quién construye y quién opera, y no hay uno correcto para todos.

Riesgo y cumplimiento

Clasificación de riesgo (risk classification) — Ubicar cada sistema de IA en un nivel de riesgo según el daño que puede causar, para aplicarle las obligaciones que corresponden. Es el primer paso de casi todo marco regulatorio. Se desarrolla en Riesgo y cumplimiento.

EU AI Act (Reglamento de IA de la Unión Europea) — La regulación europea que clasifica los sistemas de IA en cuatro niveles: riesgo inaceptable (prohibido), alto riesgo (permitido con evaluación de conformidad, supervisión y monitoreo), riesgo limitado (obligación de transparencia: avisar que es IA) y riesgo mínimo (sin obligaciones específicas). Aplica por dónde se usa el sistema, no por dónde está la empresa.

NIST AI RMF (marco de gestión de riesgos de IA del NIST) — El marco voluntario estadounidense organizado en cuatro funciones: Gobernar (cultura y políticas, cruza todo), Mapear (entender el contexto y los impactos), Medir (evaluar los riesgos) y Gestionar (actuar sobre ellos). Es una guía práctica, no una ley.

ISO/IEC 42001 — La primera norma internacional para sistemas de gestión de IA (2023). Especifica cómo establecer, implementar, mantener y mejorar un sistema de gestión de IA bajo el ciclo planificar-hacer-verificar-actuar, cubriendo transparencia, rendición de cuentas, sesgo, seguridad y privacidad. Es certificable, a diferencia del NIST AI RMF.

Protección de datos (data protection) — El conjunto de obligaciones sobre datos personales: base legal para usarlos, minimización, consentimiento, derecho de acceso y borrado. En IA es crítica porque los modelos consumen y a veces memorizan datos personales.

Sesgo / equidad (bias / fairness) — La tendencia de un modelo a tratar sistemáticamente peor a un grupo, y las técnicas para medirla y corregirla. No es solo un problema ético: es riesgo legal, reputacional y de producto.

Supervisión humana (human oversight) — El requisito de que una persona pueda revisar, corregir o revertir una decisión automatizada, sobre todo en usos de alto riesgo. Es una obligación explícita del EU AI Act para sistemas de alto riesgo.

IA responsable (responsible AI) — El paraguas de prácticas para que un sistema de IA sea justo, transparente, seguro, privado y rendible de cuentas. Es lo que traduce los principios en decisiones concretas de producto.

Transparencia (transparency) — Que el usuario sepa que interactúa con IA y, cuando corresponde, cómo y por qué el sistema decidió. Es la obligación mínima del nivel de riesgo limitado del EU AI Act.

Adopción y operación

Gestión del cambio (change management) — El trabajo de lograr que las personas adopten de verdad el nuevo sistema: comunicación, formación, incentivos y acompañamiento. Muchos proyectos de IA que “funcionan” fracasan aquí, porque nadie los usa. Se desarrolla en Lanzamiento y adopción.

Confianza del usuario (user trust) — La disposición de la persona a apoyarse en el sistema, que se gana con aciertos y se pierde con un solo error visible. En IA, donde el sistema falla de formas raras, la confianza es frágil y hay que diseñarla, no asumirla.

Rollout gradual (canary, despliegue por etapas) — Lanzar a un porcentaje pequeño de usuarios primero y ampliar solo si las métricas aguantan. Convierte un fallo potencialmente masivo en un incidente contenido y reversible.

Diseñar para el error (design for failure) — Asumir que el sistema se equivocará y diseñar la experiencia para que el error sea barato: mostrar confianza, permitir corregir, dejar salida a un humano. Un sistema de IA sin plan para sus fallos es una demo, no un producto.

Feedback loop (bucle de retroalimentación) — El circuito por el que el uso real y las correcciones vuelven a mejorar el sistema. Sin él, el producto se congela el día del lanzamiento y empieza a envejecer.

Deriva (drift) — El deterioro de la calidad cuando el mundo cambia y el modelo se queda con la foto vieja: nuevos patrones, nuevos datos, nuevo comportamiento de usuarios. Se detecta monitoreando, no esperando el reclamo. Ver Monitoreo de modelos.

Reentrenamiento (retraining) — Actualizar el modelo con datos recientes para recuperar la calidad perdida por la deriva. La decisión no es solo técnica: tiene costo, riesgo y hay que decidir cada cuánto vale la pena. Se desarrolla en Operar y evolucionar.

Deprecación (deprecation) — El retiro planificado de una función o un modelo, con aviso, migración y plazo. Un producto que nunca deprecia acumula deuda; hacerlo mal rompe la confianza de quien dependía de eso.

Ciclo de vida (lifecycle) — Las etapas por las que pasa un producto de IA: descubrimiento, construcción, lanzamiento, operación, evolución y retiro. Pensar en ciclo de vida evita el error de tratar el lanzamiento como el final en vez del comienzo. La gobernanza de todo el ciclo se conecta con Incidentes y gobernanza.

Estrategia AI-first

AI-first (IA primero) — La empresa donde la IA influye en qué se prioriza, se financia y cómo se opera; no una capa añadida, sino un criterio de decisión. La prueba de fuego: ¿la IA cambia qué iniciativas se financian? Se desarrolla en Qué significa ser una empresa AI-first.

AI-native (nativa de IA) — La empresa concebida sobre IA desde cero: sin IA no hay producto (OpenAI, Anthropic, Nubank). Un nivel más profundo que AI-first, donde la IA es la arquitectura fundacional y no una decisión estratégica sobre un negocio previo.

AI-enabled / AI-powered (habilitada / impulsada por IA) — Dos peldaños previos a AI-first: la IA mejora una tarea existente (enabled) o es una función del producto, muchas veces de marketing (powered). Si le quitas la IA y el negocio funciona igual, estás en este nivel, no en AI-first.

AI washing — El marketing de IA sin cambio operativo real, como el greenwashing pero con IA. Anunciar “IA” para subir la valoración o el precio mientras el proceso de fondo sigue igual.

Agentic organization (organización agéntica) — La empresa que rediseña procesos completos alrededor de agentes que actúan como fuerza laboral digital. Es hacia donde converge AI-first en 2026, cuando los agentes pasan de pilotos a producción.

CAIO (Chief AI Officer, director de IA) — El rol ejecutivo que dirige la estrategia de IA de la empresa, el gobierno centralizado, la priorización de casos de uso y la gestión del cambio. Cuando la IA es diferenciador central, reporta al CEO o al directorio, no a IT.

Hub-and-spoke (eje y radios) — El patrón de evolución de un Centro de Excelencia (ver la sección Equipo): centralizar temprano, cuando la experticia es escasa (el “hub”), y federar hacia los equipos (los “spokes”) a medida que madura. Evita tanto el caos descentralizado como el cuello de botella de un solo equipo.

Future-built (construida para el futuro) — El grupo de empresas (BCG) que sí captura valor de la IA a escala: ~5% del total, con mayor crecimiento de ingresos, margen y retorno al accionista que sus pares. El resto son scalers (escalando) y laggards (rezagadas).

AI theater (teatro de IA) — El nombre que la literatura AI-first le da al PoC purgatory (ver Roadmap), visto desde la empresa: muchos pilotos y demos vistosas que nunca llegan a producción ni mueven el resultado. La causa raíz suele ser no rediseñar el flujo ni medir la línea base antes de desplegar.

Shadow AI (IA en la sombra) — El uso de herramientas de IA personales por parte de los empleados, por fuera de los canales oficiales. Señal de demanda real, pero también un riesgo de gobierno: datos sensibles saliendo a servicios no aprobados.

Data flywheel (volante de datos) — El círculo virtuoso en que más uso genera más datos, que mejoran el modelo, que atrae más uso. Es la ventaja defendible de las empresas AI-native: difícil de copiar porque el competidor no tiene los datos.

Pricing por outcome (cobro por resultado) — El modelo de negocio que cobra por resultado logrado (una resolución, una conversación cerrada) en vez de por asiento o usuario/mes (per-seat). La transición per-seat → consumo → outcome es una de las señales de que la IA cambió la economía del producto. Se conecta con unit economics.

Adopción ≠ impacto — La distinción que decide si una iniciativa de IA vale: que todos usen la herramienta (adopción) no significa que el resultado operativo se mueva (impacto). Solo se prueba con línea base y grupo de control, no con encuestas de uso.

Metodología de casos de uso de IA

Arquetipo de caso de uso — La clasificación fundamental de la Metodología de casos de uso de IA: arquetipo A automatiza un flujo que ya existe (baseline observable: se mide contra lo que ya ocurre; valor por ahorro, errores o riesgo evitado; riesgo de regresión); arquetipo B crea una capacidad que no existía (baseline contrafactual, valor por ingreso o capacidad nueva, riesgo de no-adopción). Cada arquetipo se mide, se costea y se arriesga distinto.

Baseline (línea base) — El estado medido del mundo antes de la intervención: costo por transacción, tasa de error y tiempo de ciclo del proceso actual. Es la vara contra la que se calcula todo ROI. Sin baseline, el ahorro es una frase, no un número. Se desarrolla en el baseline.

Contrafactual (counterfactual) — El baseline de lo que no existe: qué pasaría en el mundo donde no construyes nada. Se arma con el universo direccionable (medido), la tasa de captura (supuesta, en rango) y el valor por unidad (histórico), descontando lo que habría ocurrido igual. Es la herramienta de valoración del arquetipo B.

Ingreso (o margen) incremental — La fracción del ingreso que el sistema causa, descontando lo que habría llegado por otros canales de todas formas. Un caso B honesto se sostiene sobre el delta, no sobre el total que toca el sistema. Si se multiplica por el margen por venta (como en el cotizador del curso), el resultado es margen incremental, no ingreso por ventas.

Scorecard de calificación — La tabla de filtros (¿problema de IA?, datos, volumen, tolerancia al error, reversibilidad) que puntúa cada idea antes de invertir en analizarla. Los primeros dos filtros son eliminatorios; los cortes de puntaje (8 y 5) son una heurística ajustable, no evidencia de viabilidad. Su trabajo es descartar la mayoría de las ideas cuando cuestan horas y no meses.

Costo por tarea, en tres capas — Amplía la entrada de la sección Presupuesto: lo que cuesta procesar una unidad de trabajo con IA se descompone en tokens (entrada + salida), infraestructura y humano en el circuito. El costo de tokens de la demo es un piso, no una estimación: en el caso del curso, el costo por tarea real resultó ~10× mayor, por la revisión humana. Se calcula en la economía de la IA.

Curva costo-calidad — La relación entre la gama del modelo y el porcentaje de salidas que requiere revisión humana: un modelo más caro que reduce la revisión puede ser el diseño más barato, porque la fila humana domina la cuenta. El óptimo no se adivina: puede ser un extremo o una cascada (modelo barato para lo fácil, escalada a uno caro para lo dudoso), y se decide con evals reales.

Cloud Value Framework (CVF) — El marco de AWS (pensado para migraciones cloud; su uso para IA es una adaptación del curso) que estructura el valor de una adopción tecnológica en cinco pilares: ahorro de costos, productividad del equipo, resiliencia operativa, agilidad de negocio y sostenibilidad. Aplicado a IA: el arquetipo A vive en los pilares 1-3 y el B en el 4 — un comité que solo mira el ahorro mata toda capacidad nueva. Ver TCO y el método AWS.

Migration Evaluator — La herramienta de AWS para casos de negocio de migración, citada por su lección metodológica: medir el costo completo del statu quo (crecimiento, errores, renovaciones) antes de proponer el cambio. El error que corrige: comparar un futuro idealizado contra un presente congelado.

Impuesto de plataforma — El costo de la infraestructura compartida (la landing zone) que el primer caso de uso paga y los siguientes usan gratis. La heurística del curso: con ≥2 casos serios en el embudo, la landing zone se evalúa como inversión de cartera — y el ROI de la cartera la incluye; cargarla entera al pionero sesga el portafolio hacia no empezar nunca.

Landing zone de IA — La plataforma mínima compartida que todo caso de IA en producción necesita: LLM gateway, FinOps de plataforma, persistencia, resiliencia (retry y fallback), ofuscación de PII, guardrails y política de datos críticos. Se construye una vez para todos los casos o se improvisa mal en cada uno. Módulo completo en la landing zone de IA.

LLM Gateway — El servicio propio por el que pasan todas las llamadas a modelos de todas las aplicaciones: normaliza proveedores, enruta y hace fallback, centraliza credenciales y audita cada llamada. Es la pieza fundacional de la landing zone porque las demás se cuelgan de ella.

Ofuscación de PII (PII masking) — Enmascarar la información personal identificable (nombres, RUT, correos, tarjetas) antes de que salga a un proveedor externo, con re-sustitución al volver. Es seudonimización, no anonimización: es reversible y el dato sigue siendo personal. El peaje de entrada de cualquier caso que toque datos de personas; también aplica a logs y datos de evaluación.

Retry con backoff (reintento con espera creciente) — Reintentar una llamada fallida esperando cada vez más entre intentos, con un tope; si la llamada ejecuta una acción, exige idempotencia. Junto con timeouts, fallback a otro modelo y colas, forma la capa de resiliencia que evita que cada incidente del proveedor sea un incidente tuyo. Su hermano obligatorio es el freno de gasto: retry sin límite + sin presupuesto duro = factura récord.

Fallback — A dónde va la llamada cuando el modelo primario falla: otro modelo, otro proveedor o una degradación honesta (“derivar a humano” es un fallback perfectamente válido).

Análisis de sensibilidad (sensitivity analysis) — Mover cada supuesto del caso a su extremo realista (los demás quietos) para ver cuánto se mueve el resultado. Revela qué variable mata el caso — y por tanto dónde gastar el esfuerzo de validación. En los casos de IA, el costo de tokens suele ser la variable menos sensible; la revisión humana y la adopción, las que mandan. Ver ROI y medición.

Payback (punto de equilibrio) — El mes en que el valor acumulado cruza el costo acumulado. Se calcula con flujos mensuales (incluida la rampa), no se deduce del ROI. Complementa al ROI: un caso con ROI alto a 3 años y payback a 30 meses compite mal contra uno modesto que se paga en 6.

Holdout (grupo de retención) — La fracción del flujo que sigue por el proceso viejo durante la medición, elegida al azar, para poder atribuir la mejora al sistema y no al azar o a cambios externos. Se decide antes del despliegue o no existe.

Embudo de adopción — La medición del arquetipo B: contactados → solicitan → reciben y responden → convierten, cada etapa con su meta. Diagnostica dónde falló (demanda, oferta, producto), pero no atribuye causa: para eso hace falta un grupo de control o un contrafactual creíble.

Gate (compuerta) — El punto de decisión binaria entre pasos de la metodología, respaldado por un artefacto (ficha, scorecard, baseline, TCO, dossier). Si el artefacto no existe, el caso no pasa. Un “go” nunca aprueba el proyecto: aprueba un piloto acotado con presupuesto y fecha de corte.

Dossier del caso de uso — El artefacto final de la metodología: dos páginas (decisión + evidencia) que integran arquetipo, baseline, economía, TCO, ROI con rango, plan de medición y riesgos con dueño. Plantilla completa en riesgos, gates y el pitch.

Material relacionado

• Qué significa ser una empresa AI-first — la definición, la evidencia global (BCG, McKinsey, MIT) y la hoja de ruta por fases.
• ¿Es un problema de IA? — cómo distinguir un caso de uso real de una solución en busca de problema.
• Del caso de uso al business case — ROI, TCO y valor cuantificado en un one-pager que finanzas acepta.
• Metodología de casos de uso de IA — la metodología de 7 pasos: arquetipos, baseline, economía, landing zone, ROI y dossier.
• Build vs buy vs API — cuándo construir, cuándo comprar y cómo evitar el vendor lock-in.
• Priorización — RICE, ICE, Kano y por qué el sunk cost no debería decidir.
• Métricas y KPI — de la métrica de modelo a la north star y su árbol de KPI.
• Presupuesto y FinOps — unit economics, costo por tarea y las palancas de costo de la IA.
• Riesgo y cumplimiento — EU AI Act, NIST AI RMF e ISO 42001 en simple.
• Operar y evolucionar — deriva, reentrenamiento y el ciclo de vida completo.
• Definir el éxito — de “que funcione bien” a criterios verificables con umbral.
• Glosario de Evals — las métricas, guardrails y evaluación detrás de “¿funciona?”.
• Incidentes y gobernanza — qué hacer cuando el sistema falla en producción.