# Evaluación de viabilidad de un caso de uso de IA

Decide si un caso de uso necesita un modelo y si existen los datos y la tolerancia al error para construirlo.

## Entregable

Un documento Markdown, `feasibility-assessment.md`, con la estructura fijada en **Salida** más abajo. Es la entrada de **Especificación de agente y prompts**.

## Entradas obligatorias

- **El caso de uso, en palabras de quien lo pide** — qué debe producir el sistema, para quién, y qué decisión o acción se sigue de su salida.
- **Los datos que existen hoy para esta tarea** — dónde están, quién puede usarlos y bajo qué condiciones.
- **El error aceptable** — qué cuesta una respuesta equivocada y quién la absorbe.

Si falta cualquiera de las tres, repórtalo como ausente y nunca la rellenes. Un caso de uso sin umbral de error aceptable se reporta como todavía no evaluable: sin él no hay nada contra lo que juzgar un resultado.

## Entradas opcionales

- El proceso sin IA que atiende hoy esta tarea y lo que cuesta mantenerlo
- Con qué frecuencia ocurre la tarea y en cuánto tiempo hace falta la respuesta
- Etiquetas, anotaciones o resultados históricos asociados a los datos existentes
- Condiciones regulatorias, contractuales o de residencia que vinculan a los datos
- Quién revisa la salida antes de que actúe, y qué ve cuando la revisa
- Intentos anteriores sobre la misma tarea y por qué se detuvieron

Cada entrada opcional que falte pasa a **Preguntas abiertas**. Nunca se convierte en una suposición, y nunca se convierte en una cifra.

## Ejecución

**1 — Reformular la tarea como una decisión.** Deja escrito qué se le pide producir al sistema, quién lo consume y qué ocurre después por su causa. Un caso de uso que no puede nombrar la acción que cambia su salida todavía no es un caso de uso — déjalo registrado y continúa.

**2 — Comprobar si hace falta un modelo.** Describe la ruta determinista — una regla, una consulta, un formulario, una persona siguiendo un procedimiento — que produciría la misma salida. Si esa ruta existe y cumple el error aceptable, esa es la recomendación. Un modelo solo se justifica donde la ruta determinista falla, y este paso nombra dónde falla.

**3 — Establecer la línea de base.** Registra cómo se hace hoy la tarea y qué consigue, con las mediciones que aporte quien lo pide. Si no se ha medido nada, escribe `desconocido` y nombra qué hay que medir antes de que pueda existir comparación alguna. Un sistema sin línea de base no puede demostrarse como mejora de nada.

**4 — Auditar los datos.** Por cada fuente: qué contiene, si está etiquetada para esta tarea, quién puede usarla para este fin y bajo qué condiciones, y si representa a la población que el sistema encontrará en producción. Marca cada respuesta como `verificado` si se inspeccionó un documento o una muestra, `reportado` si lo afirmó una persona, y `desconocido` en cualquier otro caso.

**5 — Definir el error aceptable.** Las dos direcciones por separado — qué cuesta una respuesta equivocada en cada una, quién la absorbe y si se puede revertir. Si quien lo pide no puede enunciarlo, la evaluación termina aquí con el veredicto `todavía no evaluable`, porque todo juicio posterior depende de ello.

**6 — Acotar la ambigüedad irreducible.** Haz que más de una persona cualificada responda los mismos casos por separado y registra dónde discrepan. Donde discrepan personas competentes, ningún sistema coincide con todas, y el objetivo se sitúa por debajo de ese techo. Si esto no se ha hecho, registra el techo como `sin medir` y llévalo como condición del veredicto.

**7 — Escribir el veredicto.** `adelante`, `no seguir` o `todavía no evaluable`, con la evidencia que lo produjo, las condiciones que lo cambiarían y qué debe ser cierto antes de empezar la siguiente etapa.

## Salida

`feasibility-assessment.md`, en este orden:

- **1. Caso de uso y fecha** — el caso de uso tal como se recibió, su fuente y cuándo
- **2. Decisión a la que sirve** — para qué es la salida, quién la consume, qué acción se sigue
- **3. Ruta sin IA** — la alternativa determinista o manual, y dónde falla
- **4. Línea de base** — cómo se hace hoy la tarea y qué consigue
- **5. Auditoría de datos** — por fuente: contenido, etiquetas, permiso, representatividad, y la marca `verificado`, `reportado` o `desconocido`
- **6. Error aceptable** — cada dirección, su coste, quién lo absorbe, si es reversible
- **7. Techo de ambigüedad** — dónde discrepan las personas cualificadas, y qué techo fija eso
- **8. Veredicto** — adelante, no seguir o todavía no evaluable, con la evidencia que lo sostiene
- **9. Condiciones y preguntas abiertas** — qué cambiaría el veredicto, qué falta, quién puede aportarlo

## Validación

La evaluación está lista cuando se cumple todo esto:

- La sección 2 nombra la acción que cambia por causa de la salida
- La sección 3 enuncia la ruta determinista y si es suficiente
- La sección 6 enuncia las dos direcciones del error y quién absorbe cada una
- Cada afirmación de la sección 5 está marcada como `verificado`, `reportado` o `desconocido`
- La sección 8 lleva uno de los tres veredictos permitidos, con la evidencia que lo sostiene
- No aparece ninguna cifra de acierto, volumen o coste que no venga de una entrada

Falla la ejecución si el veredicto es `adelante` mientras la sección 6 está vacía, o si alguna cifra del documento no tiene fuente.

## Gestión de fallos

- **Sin umbral de error aceptable** — produce las secciones 1 a 5, marca la sección 8 como `NO EVALUABLE` y nombra a quién debe fijar el umbral. Un veredicto sin él es una preferencia.
- **Sin inventario de datos** — produce la sección 5 como la lista de fuentes que hay que inventariar, y marca el veredicto como `PROVISIONAL`. Nunca supongas que los datos existen porque el caso de uso los necesita.
- **Sin acceso a los datos ni al proceso actual** — las secciones 4 y 5 quedan solo como `reportado`. Declara que no se verificó nada y que el veredicto hereda esa incertidumbre.
- **Entradas contradictorias** — registra las dos, nombra ambas fuentes y eleva la contradicción a la sección 9 como bloqueante. No la resuelvas eligiendo.
- **Material parcial** — produce cada sección que el material sostenga, marca el resto como `INCOMPLETO — pendiente de <pregunta>` y entrega.