# Cuando una herramienta falla: una muestra de cómo planteo una entrega

Max Bonàs · Consultoría y formación en IA aplicada

## El problema

Una demo responde correctamente una vez. El equipo todavía necesita saber qué ocurre si la herramienta falla, si recibe una entrada incorrecta o si alguien pide algo fuera de su alcance. También necesita poder continuar sin depender de quien construyó la demo.

Esta muestra utiliza cuatro situaciones ficticias. No contiene datos de clientes, no llama a un modelo ni conecta con servicios externos.

## Las decisiones

Antes de repetir una operación, distinguir un fallo temporal de una entrada que necesita corregirse. Limitar los intentos. Comprobar el alcance antes de ejecutar. Separar una propuesta preparada de una acción aprobada.

| Situación | Respuesta esperada | Qué puede revisar el equipo |
|---|---|---|
| Un fallo temporal y después una respuesta correcta | Dos intentos; propuesta pendiente de revisión | Recuperar no equivale a autorizar |
| La herramienta sigue fallando | Tres intentos; intervención de una persona | El proceso termina y pide ayuda |
| La petición queda fuera del alcance | Rechazo; cero intentos | El límite se aplica antes de actuar |
| La entrada es inválida | Se detiene tras un intento | Repetir no arregla una entrada incorrecta |

## Verlo y repetirlo

Descarga [el ejemplo de recuperación](entrega-recuperacion.mjs). Con Node.js 24, ejecuta en la carpeta de descarga:

```sh
node entrega-recuperacion.mjs
```

La salida describe los cuatro escenarios y comprueba sus resultados. `externalActions: 0` significa que este ejemplo no realiza acciones externas; no demuestra la seguridad de una integración real.

Para comprobar que se ha entendido, antes de mirar la solución responde: si la entrada es inválida y después hay una respuesta correcta disponible, ¿cuántos intentos debe hacer? Uno: primero hay que corregir la entrada. Explica también quién debe intervenir cuando se agotan los intentos.

## Qué quedaría por hacer en un producto real

Evaluar las respuestas del modelo, los permisos, los costes y la latencia. Probar reinicios y operaciones que no deben duplicarse. Acordar quién revisa las propuestas y cómo recupera el trabajo. Nada de eso queda acreditado por esta simulación.

En una colaboración, la entrega se acuerda para el caso concreto: escenarios, resultados esperados, prioridades e instrucciones de continuidad. La muestra ilustra mi enfoque; no acredita resultados de clientes.

[Instrucciones y rúbrica de autonomía](README.md) · [Consultar un prototipo](https://maxbonas.com/agenda?reason=consulting) · [Formar a un equipo](https://maxbonas.com/agenda?reason=training)