Redactar la decisión y el plan piloto de IA local

El objetivo final no es demostrar que puedes ejecutar un modelo local. Es decidir si esa arquitectura merece incorporarse al sistema de la empresa.

La decisión debe poder revisarse dentro de seis meses sin depender de memoria.

Resume el problema

Una página:

• tarea;
• usuarios;
• volumen;
• datos;
• situación actual;
• por qué se evaluó local.

Evita:

«Por privacidad.»

Escribe:

«Los documentos X no pueden salir de la red Y durante inferencia y necesitamos operación sin WAN durante Z horas.»

Lista requisitos

Separa:

MUST Bloqueantes.

SHOULD Importantes.

OPTIONAL

Ejemplo:

MUST
quality >= baseline - tolerance
no internet during inference
p95 < 4 s
license reviewed

SHOULD
single-server
cost < API at expected load

Alternativas

Incluye:

1. mantener API;
2. local;
3. híbrido;
4. no implementar.

Una decisión profesional puede ser «no local».

Evidence pack

Adjunta:

• dataset;
• eval results;
• benchmark;
• hardware;
• model card;
• license;
• runtime;
• architecture;
• threat model;
• cost model;
• sensitivity.

No incluyas solo una conclusión.

Tabla de decisión

Para cada score, enlaza evidencia.

Riesgos residuales

Local:

• hardware failure;
• patching;
• security;
• model aging;
• capacity.

API:

• provider;
• price;
• data exposure;
• network.

Híbrido:

• complexity;
• routing;
• dual validation.

Asigna owner.

Decisión

Formato:

«Recomendamos un piloto local para la tarea X, limitado a usuarios Y, porque cumple A/B/C. No se recomienda sustituir la API en tareas Z porque el modelo local no alcanza el umbral Q.»

O:

«No recomendamos local actualmente. El ahorro estimado no compensa CAPEX y la calidad es inferior. Reevaluar si el volumen supera N o aparece hardware disponible.»

No uses números eternos

Precios, modelos y hardware cambian.

Incluye:

• valid_until;
• triggers.

Ejemplos:

• nuevo modelo;
• cambio de precio API;
• crecimiento 2×;
• hardware amortizado;
• nueva política.

Plan piloto

Scope

• 10 usuarios;
• 1 tarea;
• 1 modelo;
• read-only;
• datos autorizados.

Fases

Offline Benchmark.

Shadow Local ejecuta pero no responde.

Cohort Usuarios limitados.

Decision Comparar.

Seguridad

Antes:

• auth;
• firewall;
• secrets;
• logs;
• data retention;
• egress.

Prueba.

Operación

Runbooks:

• OOM;
• model server down;
• GPU failure;
• update;
• fallback.

Define:

• owner;
• support hours.

Fallback

Puede ser:

• API;
• manual;
• cola.

Debe respetar los mismos requisitos de privacidad. No hagas fallback a cloud si el MUST era «datos no salen».

Criteria de avance

Ejemplo:

GO

• quality pasa;
• p95;
• cost;
• 0 critical security.

HOLD

• calidad aceptable, operación inmadura.

NO-GO

• incumple MUST.

Criterio de retirada

Define:

• uso bajo;
• coste;
• incapacidad de actualizar;
• vulnerabilidad;
• mejor alternativa.

Retirar:

• modelo;
• logs;
• credenciales;
• hardware reuse;
• documentación.

Licencia y revisión

Una model card puede indicar licencia y uso previsto, pero la empresa debe conservar la versión de la licencia revisada.

Si no está claro:

• no despliegues;
• escala.

No infieras «open weights = libre para cualquier uso».

Dossier final

Entrega:

1. executive summary;
2. requisitos;
3. modelos;
4. hardware;
5. licencias;
6. arquitectura;
7. evals;
8. performance;
9. TCO;
10. seguridad;
11. riesgos;
12. piloto;
13. triggers;
14. decisión.

Executive summary

La primera página debe responder:

1. ¿qué decidimos?
2. ¿por qué?
3. ¿con qué evidencia?
4. ¿qué riesgo queda?
5. ¿cuándo revisamos?

Evita empezar por detalles de GPU.

Confidence de la decisión

Clasifica:

High resultados estables; supuestos probados.

Medium uno o dos supuestos relevantes.

Low precios, volumen o calidad inciertos.

Si confidence es baja, la decisión puede ser «pilotar», no «comprar».

Opciones descartadas

Documenta:

• candidato;
• motivo.

Ejemplo:

«Modelo B descartado por licencia no aprobada.»

Esto evita repetir trabajo.

Procurement

Si vas a comprar hardware, no compres antes del benchmark si puedes:

• alquilar;
• usar cloud GPU;
• pedir demo;
• reutilizar workstation.

Reduce riesgo CAPEX.

Piloto con tiempo

Define:

start
end
review

Un piloto sin fecha puede convertirse en producción accidental.

Exit criteria

Incluye:

• success;
• failure.

Ejemplo:

Success pasa MUST durante 4 semanas.

Failure quality crítica < threshold.

No muevas la meta.

Owner y presupuesto

Define:

• technical owner;
• business owner;
• budget;
• soporte.

Si nadie operará el server, no es viable aunque el benchmark pase.

Security sign-off

Registra:

• amenazas;
• controles;
• riesgos abiertos.

No uses «está en local» como sign-off.

License sign-off

Conserva:

• texto/licencia;
• versión;
• revisor;
• fecha.

Una URL que cambie no es evidencia histórica suficiente.

Revisión post-piloto

Compara:

• benchmark esperado;
• producción real.

Observa:

• usage;
• p95;
• tickets;
• cost;
• incidents.

Decisión final

Opciones:

ADOPT_LOCAL
ADOPT_HYBRID
KEEP_API
RETEST
STOP

Con motivo.

Roadmap

Si adoptas:

• capacidad;
• HA;
• modelos futuros;
• actualización.

No construyas todo durante piloto.

Comunicación

Explica al negocio qué cambia:

• SLA;
• capacidades;
• límites.

No vendas «privacidad total» o «coste cero por uso».

Una decisión técnica madura también comunica lo que local no resuelve.

Ejercicio final

Produce el informe.

Después pide a otro responsable que responda:

• ¿por qué local?
• ¿qué se midió?
• ¿qué no?
• ¿cuánto cuesta?
• ¿qué riesgo queda?
• ¿qué hace cambiar la decisión?

Si no puede responder, el informe todavía no es operativo.

Cierre

IA local no es una categoría superior ni inferior a cloud.

Es una opción de despliegue que merece adoptarse cuando satisface mejor requisitos concretos de calidad, datos, latencia, continuidad, coste y control después de incluir el trabajo de operarla.

El resultado del minicurso es una decisión defendible y revisable, no una preferencia tecnológica.