Empieza por una fricción observada
La primera iniciativa de IA no debería nacer de una lista de herramientas. Recoge diez tareas repetidas durante una semana y describe entrada, salida, frecuencia, tiempo, errores y responsable. Elige problemas donde una mejora pueda observarse sin reorganizar toda la empresa.
En Chile, los resultados de Chequeo Digital citados por el Ministerio de Economía muestran que una mayoría de empresas evaluadas se ubica en niveles iniciales o novatos. Ese dato describe la muestra de la herramienta, no todas las pymes. La implicación práctica es prudente: muchos equipos necesitan ordenar procesos y datos al mismo tiempo que aprenden IA.
Un piloto pequeño protege esa capacidad limitada y produce aprendizaje propio.
Evalúa valor, riesgo y preparación de datos
Valor pregunta cuánto tiempo, calidad o capacidad podría mejorar y para quién. Riesgo considera error, privacidad, dinero, reputación, derechos y reversibilidad. Preparación de datos revisa disponibilidad, permiso, calidad, formato y dueño.
Puntúa cada eje con evidencia breve, no intuición. Un caso de alto valor y datos listos puede seguir descartado si ejecuta pagos sin control. Uno de valor moderado, bajo riesgo y datos preparados puede ser el mejor primer aprendizaje.
Añade una condición de descarte. Si el caso usa datos sin autorización, toma una decisión que afecta derechos o no permite revisión, no compite con los demás hasta resolver ese bloqueo. El semáforo crítico prevalece sobre la suma.
Usa la matriz para conversar, no para esconder juicio detrás de una suma. Explica por qué cada tarjeta ocupa su lugar.
Buenos primeros casos
Búsqueda sobre documentos aprobados, borrador de respuestas internas, clasificación asistida de solicitudes y resumen de reportes suelen permitir revisión antes del efecto. El dato ya existe, la salida es visible y una persona puede corregir.
Acota la colección, el tipo de usuario y la duración. Un buscador sobre veinte procedimientos es mejor piloto que "pregunta cualquier cosa sobre la empresa". Un borrador de correo que nunca se envía solo es mejor que un agente con bandeja completa.
Elige una tarea frecuente pero no trivial. Si sólo aparece una vez al mes, el piloto demorará demasiado en reunir evidencia. Si la respuesta es siempre idéntica, una plantilla o regla puede resolverla con menos costo y variabilidad.
El primer caso debe enseñar sobre calidad y operación sin exigir confianza ciega.
Casos que conviene posponer
Aplaza pagos, contratación, despidos, decisiones crediticias, cambios de precio, asesoría sensible y mensajes públicos automáticos. También pospone casos cuyo dato no tiene dueño o permiso claro.
No significa que nunca puedan abordarse. Requieren controles, evaluación, revisión legal o sectorial y evidencia que una primera prueba aún no tiene. Si el error es difícil de revertir o afecta derechos, el umbral debe ser mayor.
Un caso atractivo puede quedar fuera por una sola condición crítica. La matriz no promedia riesgos intolerables.
Prepara un conjunto pequeño y autorizado
Selecciona ejemplos representativos, elimina datos personales innecesarios y documenta fuente, permiso, fecha y exclusiones. Separa entrenamiento, evaluación y demostración aunque el piloto no ajuste un modelo. No uses las mismas respuestas para diseñar y juzgar.
Define una referencia humana o regla para cada caso. Si dos personas expertas discrepan, registra la ambigüedad. El modelo no puede resolver una política que la empresa no ha decidido.
Incluye casos difíciles y fallas históricas, no sólo ejemplos ordenados. Revisa duplicados para evitar que una misma situación aparezca en diseño y evaluación con distinto nombre. Versiona el conjunto y registra cada cambio.
Conserva los datos localmente cuando sea posible en la primera fase. No conectes el sistema completo para ahorrar el trabajo de seleccionar.
Piloto local de cuatro semanas
Semana uno: línea base y veinte a treinta casos. Semana dos: prototipo aislado con salida no ejecutable. Semana tres: uso acompañado por un grupo pequeño y registro de correcciones. Semana cuatro: evaluación, entrevista y decisión.
Mide éxito por tarea, tiempo total incluido el control humano, clases de error, porcentaje de resultados corregidos y guardrails. No uses sólo satisfacción. Una herramienta agradable puede trasladar trabajo o introducir errores silenciosos.
Define antes de empezar quién puede ver los datos, dónde se guardan y cuándo se eliminan. Registra versión de modelo, instrucciones y herramienta. Sin esa captura, una mejora o deterioro posterior no tendrá explicación.
Mantén producción desconectada. La salida se copia o aprueba manualmente. Cualquier integración posterior es otra versión y otra decisión.
Decide continuar, rediseñar o detener
Continúa si mejora el resultado definido, los errores son comprendidos, la revisión cabe en la operación y los datos tienen gobierno. Rediseña si el valor existe pero la interfaz, el alcance o la base de conocimiento producen fallas corregibles. Detén si el dato no está autorizado, el riesgo supera el beneficio o la revisión cuesta tanto como la tarea original.
Documenta también qué no funcionó. Esa evidencia evita repetir el mismo piloto con otra herramienta y otro nombre. Si avanzas, define dueño, presupuesto, soporte, evaluación recurrente y plan de salida.
Para avanzar a integración, prepara una segunda compuerta: identidad técnica, permisos mínimos, observabilidad, respaldo, reversa y aprobación de efectos. Un piloto de contenido no autoriza por extensión acceso a clientes o sistemas transaccionales.
La decisión no necesita defender la inversión anterior. Necesita proteger el próximo paso.
Plantilla de selección
1. Problema observado y frecuencia.
2. Usuario y resultado esperado.
3. Línea base de tiempo, calidad o volumen.
4. Valor potencial con supuestos.
5. Riesgos, afectados y reversibilidad.
6. Datos: fuente, permiso, calidad y dueño.
7. Alcance excluido.
8. Casos de evaluación y guardrails.
9. Revisión humana y criterio de término.
10. Decisión al cierre del piloto.
La primera victoria no es desplegar IA. Es aprender, con una inversión controlada, si un problema concreto merece convertirse en producto o automatización.
