Producto + IA · Ensayo 01
Diseñar con IA sin perder criterio de producto
La inteligencia artificial puede acelerar una tarea. El diseño de producto decide si esa tarea merece acelerarse, qué evidencia falta y quién responde por el resultado.
La conversación sobre IA suele empezar por la herramienta: qué modelo usar, qué agente construir o qué parte del flujo automatizar. Yo prefiero empezar un paso antes. Pregunto qué decisión necesita mejorar, qué información la sostiene y qué daño podría producir una respuesta plausible pero incorrecta.
Esa diferencia parece pequeña, pero cambia el proyecto completo. Cuando la herramienta aparece primero, el equipo busca dónde instalar una capacidad disponible. Cuando aparece primero la decisión, la tecnología compite con otras maneras de resolver el problema y debe demostrar por qué merece entrar al sistema.
La velocidad no reemplaza el criterio
Generar diez alternativas en segundos puede ser útil. También puede producir diez variaciones del mismo supuesto equivocado. La velocidad multiplica tanto una buena dirección como una mala. Por eso no la considero valor en sí misma: es una fuerza que necesita orientación.
En producto, el criterio conecta una acción con una consecuencia. Permite distinguir una salida atractiva de una respuesta útil, una correlación de una señal y una automatización eficiente de una experiencia que simplemente trasladó el costo a otra persona. No se trata de desconfiar de la IA; se trata de darle una posición clara dentro de una cadena de decisiones.
La pregunta importante no es “¿qué puede generar el modelo?”, sino “¿qué decisión será mejor gracias a esta capacidad?”.
Si un asistente resume entrevistas, por ejemplo, su valor no está en producir menos texto. Está en ayudar a que el equipo encuentre patrones sin borrar desacuerdos, casos extremos o contexto. Un resumen veloz que aplana la evidencia puede ahorrar minutos y empeorar la decisión posterior.
Definir la decisión antes de elegir la herramienta
Antes de hablar de prompts, integraciones o modelos, escribo una frase: “Al terminar este paso, alguien necesita decidir…”. La frase obliga a identificar un actor, un momento y una responsabilidad. También revela si la tarea realmente requiere predicción, generación, clasificación o solo una mejor estructura de información.
Después busco el costo actual de esa decisión. Puede ser demora, inconsistencia, pérdida de información o carga cognitiva. No necesito inventar una métrica espectacular; necesito observar dónde se produce la fricción. A veces la mejor solución es una plantilla bien diseñada. Otras veces, la cantidad de señales y excepciones justifica asistencia inteligente.
También separo dos preguntas que suelen mezclarse: “¿puede hacerlo?” y “¿conviene que lo haga?”. Una demostración puede responder la primera. La segunda exige entender frecuencia, consecuencias, privacidad, trazabilidad y capacidad de supervisión. Una función técnicamente posible puede ser operacionalmente irresponsable.
Esta formulación cambia la selección tecnológica. Si la decisión necesita explicar fuentes, el sistema debe priorizar recuperación y trazabilidad. Si necesita creatividad, puede aceptar mayor variación. Si afecta seguridad o dinero, debe reducir autonomía y aumentar revisión. La arquitectura emerge del riesgo, no de la moda.
Un marco de cuatro capas
Uso cuatro capas para ordenar una oportunidad de IA. No reemplazan investigación ni pruebas, pero permiten detectar rápidamente dónde una propuesta todavía es débil.
Una fricción observable
Qué tarea, decisión o traspaso está fallando; para quién; con qué frecuencia y en qué contexto.
Información suficiente
Qué datos existen, quién los produce, qué sesgos contienen y qué señales faltan para sostener una respuesta.
Un borde explícito
Qué no debe decidir el sistema, qué errores son aceptables y cuándo debe detenerse o pedir intervención.
Una consecuencia verificable
Quién usa la salida, qué cambia después y cómo sabremos si la capacidad mejoró el resultado.
Las capas funcionan como dependencias. Sin un problema observable, la evidencia no tiene dirección. Sin evidencia, el modelo rellena vacíos con probabilidad. Sin límites, la salida adquiere una autoridad que no merece. Sin una decisión posterior, el sistema produce contenido pero no capacidad.
Un buen piloto puede ser pequeño: una muestra acotada, un solo tipo de usuario y revisión manual completa. Lo importante es que recorra las cuatro capas. Prefiero un experimento modesto que permita aprender sobre el sistema a una demo amplia que solo confirme que el modelo sabe producir algo convincente.
Diseñar el lugar del juicio humano
“Humano en el circuito” no debería ser una frase tranquilizadora al final de una presentación. Es una decisión de interfaz y operación. Hay que definir qué ve esa persona, cuánto tiempo tiene, qué puede corregir y qué sucede con esa corrección.
Una revisión humana sin contexto puede convertirse en aprobación automática. Si el sistema entrega una recomendación pulida pero oculta sus fuentes, incertidumbre o alternativas, la interfaz empuja a confiar. La supervisión real necesita fricción útil: comparar evidencia, mostrar por qué se propuso algo y facilitar que el usuario rechace la salida.
También importa quién aprende. Si una persona corrige siempre el mismo error y el sistema no registra el patrón, la organización paga dos veces: primero por la equivocación y luego por una supervisión que no mejora la capacidad. Diseñar retroalimentación significa decidir qué cambios alimentan reglas, datos o entrenamiento y cuáles deben permanecer como excepciones locales.
Evaluar el sistema, no solo la respuesta
Una salida individual puede parecer correcta y aun así ocultar un comportamiento frágil. Por eso conviene evaluar conjuntos de casos que representen situaciones frecuentes, datos incompletos y bordes sensibles. Registro no solo si la respuesta fue aceptada, sino cuánto trabajo exigió revisarla, qué fuentes faltaron y qué tipos de corrección se repiten.
Esa evaluación necesita una cadencia. Antes de lanzar se define una línea base; durante el piloto se revisan casos de forma cercana; cuando la capacidad madura, se monitorean cambios en datos, uso y errores. Si el contexto cambia, una buena solución anterior puede dejar de serlo. El criterio de producto incluye decidir cuándo volver a probar, reducir alcance o retirar una función.
En tareas sensibles, una buena solución puede ser deliberadamente menos autónoma. Asistir en la preparación, señalar anomalías o sugerir próximos pasos mantiene velocidad sin delegar la responsabilidad final. La madurez no se mide por cuántos pasos ejecuta la IA, sino por cuánta claridad aporta al sistema completo.
Checklist para evaluar una oportunidad de IA
Antes de construir, revisaría estas preguntas con las personas que conocen el proceso y con quienes recibirán sus consecuencias:
- ¿Qué decisión concreta debería mejorar y quién es responsable de tomarla?
- ¿Qué evidencia demuestra que el problema ocurre y no es solo una impresión?
- ¿La tarea necesita variación probabilística o bastaría una regla, plantilla o cambio de flujo?
- ¿Qué fuentes puede consultar el sistema y cómo verá el usuario su procedencia?
- ¿Qué tipo de error es tolerable, cuál es costoso y cuál es inaceptable?
- ¿En qué momento debe pedir ayuda, abstenerse o devolver el control?
- ¿La persona revisora tiene contexto y autoridad real para corregir?
- ¿Cómo se registrarán las correcciones sin convertir cada excepción en una regla?
- ¿Qué cambio observable indicaría que la decisión mejoró?
- ¿Podemos probar la hipótesis con un alcance menor antes de integrar la capacidad al flujo principal?
Aplicar IA con criterio no significa avanzar lento. Significa mover rápido las preguntas difíciles para no descubrirlas cuando la tecnología ya está conectada a usuarios, datos y decisiones reales.