Cómo escribir un PRD para un proyecto de IA (y no uno de software)

Por qué un PRD de software no te sirve para un proyecto de IA

La mayoría de los PRD de IA que reviso son PRD de software con la palabra “IA” pegada encima. Copian la estructura de un documento de producto normal: objetivo, historias de usuario, criterios de aceptación, mockups. El problema es que un sistema de IA no tiene una salida fija. No es “cuando el usuario hace clic en X, pasa Y”. Es “el sistema decide, dentro de un rango de comportamiento, qué hacer con una situación que nadie escribió explícitamente”. Si el PRD no anticipa eso, el límite de lo que el sistema puede decidir lo termina fijando el modelo en producción, no el equipo que lo diseñó.

El resultado de un PRD mal escrito no es que el proyecto no arranque. Es peor: arranca, se construye, y falla en el primer caso que nadie imaginó. Nadie sabe si esa falla era esperable o un error real. Nadie sabe a quién escalar. Y nadie puede decir, con un número en la mano, si el sistema está funcionando o no. Eso no es un problema de ingeniería. Es que el PRD nunca documentó las cinco cosas que sí cambian frente a un PRD de software: el KPI, los datos, el límite de autonomía, el criterio de éxito y el plan de errores.

Esta guía asume que ya tienes claro por qué tu empresa necesita un sistema de IA y qué caso de uso vas a atacar primero. Lo que sigue es el paso siguiente: cómo se escribe el documento que el equipo técnico va a usar para construir, sección por sección, sin relleno.

Qué es un PRD de IA, en concreto

Un PRD de IA no es un documento de intención (“queremos usar IA para mejorar X”). Tampoco es una lista de funcionalidades (“el sistema va a responder preguntas, generar reportes y enviar alertas”). Es el documento que amarra tres cosas antes de que exista una sola línea de código: el dolor de negocio con su número actual, los datos reales con los que el sistema va a decidir, y el límite exacto de lo que puede hacer sin que un humano lo revise.

La diferencia con un PRD de software tradicional no está en el formato (documento, secciones, responsables). Está en el contenido de esas secciones. Un PRD de software especifica comportamiento determinístico: dado este input, este output. Un PRD de IA especifica un espacio de decisión: dado este contexto, estos datos y estas reglas, el sistema decide dentro de estos límites, y fuera de ellos, se detiene y pregunta.

El paso a paso: qué documentar y en qué orden

Sigue este orden al escribir el documento. Cada punto es una sección que puedes copiar en tu propio PRD; lo que cambia es el contenido, no la estructura.

1. El dolor y el KPI que debe moverse (no la lista de features)

No escribas “el sistema va a automatizar la atención al cliente”. Escribe el dolor con un número: “el equipo de soporte responde en 6 horas promedio y el 30% de los tickets se abandona antes de la primera respuesta”. El PRD arranca con ese número, no con la funcionalidad. Después define el KPI objetivo (a qué número quieres llegar, en qué plazo) y quién en la empresa es dueño de ese número: si nadie tiene su nombre puesto al lado del KPI, el proyecto no tiene quién lo defienda en la siguiente revisión de presupuesto.

2. Qué datos necesita el sistema y de dónde salen

Por cada dato que el sistema va a usar para decidir, documenta: de qué sistema sale (CRM, ERP, hoja de cálculo, correo), en qué formato llega, cada cuánto se actualiza, quién es el dueño de ese dato dentro de la empresa, y qué tan limpio está en realidad (no lo que dice el manual, lo que se ve al abrir la base). Si un dato crítico no existe todavía o vive disperso en varios archivos, eso no es un detalle técnico para resolver después: es un riesgo que el PRD tiene que nombrar antes de aprobar presupuesto de construcción.

3. El límite de autonomía: qué decide el sistema solo y qué no

Esta es la sección que casi nadie escribe y la que más problemas evita. Divide las acciones del sistema en tres columnas: lo que ejecuta solo sin que nadie lo revise, lo que requiere aprobación humana antes de ejecutarse, y lo que tiene explícitamente prohibido hacer aunque técnicamente pueda. No es una restricción técnica, es una decisión de negocio: cuánto riesgo acepta la empresa en ese proceso específico. Un sistema que envía correos de seguimiento a leads tibios puede tener autonomía casi total; uno que aprueba créditos o modifica contratos, no.

4. El criterio de éxito medible, antes de construir

Antes de escribir una línea de código, el PRD responde: ¿cuál es el número hoy (el punto de partida)?, ¿a qué número se quiere llegar?, ¿en qué plazo?, ¿quién firma que se cumplió? Si esta sección se llena después de construir, no es un criterio de éxito, es una justificación retroactiva. Y una justificación retroactiva siempre encuentra la forma de decir que el proyecto “sí funcionó”, aunque el número real no se haya movido.

5. El plan de manejo de errores y excepciones

Un sistema de IA se va a encontrar con una situación que nadie anticipó. Eso no es una falla de diseño, es la naturaleza del problema. Lo que sí es una falla de diseño es no tener un plan para ese momento. El PRD documenta: qué hace el sistema cuando no tiene suficiente confianza para decidir (se detiene, pregunta, escala), a quién llega esa escalación (con nombre y canal, no “al equipo”), qué se registra de cada excepción, y cada cuánto se revisan esos registros para ajustar el sistema.

La plantilla de secciones que puedes copiar hoy

Si necesitas algo para copiar hoy mismo y llenar sección por sección, esta es la plantilla mínima. No es un ensayo sobre PRD, son los encabezados con su propósito exacto:

• Resumen ejecutivo: dos o tres frases con el dolor, el KPI objetivo y quién es el dueño del resultado dentro de la empresa.
• Dolor y contexto de negocio: qué proceso duele hoy, con qué número actual, medido cómo y desde cuándo.
• Caso de uso y alcance: qué decisión o tarea específica automatiza el sistema, y qué queda explícitamente fuera de este PRD.
• Datos de entrada: fuente, formato, frecuencia de actualización, dueño y calidad conocida de cada dato que el sistema necesita para decidir.
• Límite de autonomía: tabla de qué ejecuta el sistema solo, qué requiere aprobación humana antes de ejecutarse, y qué está prohibido.
• Criterio de éxito medible: número base (hoy), meta numérica, plazo para alcanzarla y quién firma que se cumplió.
• Plan de errores y excepciones: qué hace el sistema cuando no tiene confianza suficiente, a quién escala y qué queda registrado de cada caso.
• Riesgos y dependencias: qué puede romper el proyecto (dato que no llega a tiempo, proveedor que cambia su API, cambio regulatorio del sector).
• Plan de rollout: alcance del piloto, criterio numérico para escalarlo al resto de la empresa, y criterio para apagarlo si no cumple el KPI.

Los errores que veo en casi todos los PRD de IA que reviso

Estos son los errores que veo repetidos, casi en el mismo orden, al revisar PRD de proyectos de IA que se atrasaron o cayeron en producción.

• Escribir el PRD como lista de features de IA. “Va a resumir, va a clasificar, va a responder” describe funciones, no resuelve qué dolor de negocio se ataca ni qué número debe moverse.
• Dejar el límite de autonomía implícito. Si el documento no dice explícitamente qué puede decidir el sistema solo, el equipo de ingeniería termina decidiéndolo por su cuenta, a mitad de la construcción, sin que nadie del negocio lo haya aprobado.
• Asumir que los datos “ya están ahí”. Nadie verificó de dónde sale cada dato ni qué tan limpio está hasta que el sistema ya estaba en construcción y empezó a fallar por datos incompletos o duplicados.
• Definir el criterio de éxito después de construir. Sin un número base y una meta escritos antes, cualquier resultado se puede maquillar como éxito, y eso hace imposible aprender algo real del proyecto.
• No documentar el plan de errores. El sistema encuentra su primer caso raro en producción, nadie sabe si detenerse o seguir, y la decisión termina tomándola quien esté de turno esa tarde, no el criterio de negocio que debía estar en el PRD.

Cómo se ve en la práctica

Una empresa de logística mediana, Perú, quería un sistema que diera seguimiento a las entregas y avisara a los clientes cuando había un retraso. La primera versión del PRD que trajo el equipo interno decía, literal: “el sistema va a monitorear las entregas y notificar proactivamente a los clientes usando IA”. Eso no es un PRD, es una idea.

Se reescribió con las cinco piezas. El dolor: 18% de los clientes llamaba a soporte preguntando por su pedido antes de que la empresa avisara del retraso, y cada llamada costaba tiempo de un agente. El KPI: bajar esas llamadas a menos de 5% en tres meses. Los datos: el sistema de tracking del transportista (con retraso de hasta 40 minutos), el CRM de clientes (dueño: área comercial) y el historial de rutas, con calidad irregular.

El límite de autonomía quedó así: el sistema notifica solo cuando el retraso supera 30 minutos sobre el estimado, pero si supera 4 horas, un humano revisa la notificación antes de enviarla, porque ahí entra en juego la relación comercial. El plan de errores: si la API del transportista no responde, el sistema no inventa un estado, marca el pedido como “sin información” y escala a un agente humano en menos de 15 minutos. Escrito antes de construir, eso evitó una discusión completa a mitad de proyecto sobre qué hacer cuando el proveedor externo fallara.

Mi criterio

Cómo saber si el PRD está bien escrito

Un PRD de IA está bien escrito cuando cualquier persona del equipo, sin haber estado en la reunión donde se discutió, puede leerlo y responder cuatro preguntas sin adivinar nada.

• ¿Cuál es el número que tiene que moverse, y cuál es hoy?
• ¿Qué puede decidir el sistema solo, y qué necesita aprobación humana?
• ¿De dónde sale cada dato que usa el sistema, y qué tan confiable es?
• ¿Qué pasa exactamente cuando el sistema no sabe qué hacer?

Si alguna de esas cuatro respuestas no está en el documento, o está escrita en términos vagos (“se evaluará”, “dependerá del caso”), el PRD no está terminado, sin importar cuántas páginas tenga. Un PRD de IA bien escrito suele ser más corto que un PRD de software tradicional, no más largo: la claridad ocupa menos espacio que el relleno.