Se encuentra usted aquí
Hay un mito que circula en demos de temporada: «modo sombra es retrasar el lanzamiento». No. En Palma de Mallorca, Ibiza y Menorca, el modo sombra es la diferencia entre un agente que propone y un agente que escribe basura en el CRM el mismo día que llegan los ferries y se agotan las limpiezas. Dry-run no es cobardía; es no dejar que un modelo invente un check-out o un precio mientras tu equipo de campo está en la carretera o sin cobertura estable.
Si estás pensando en desarrollo de aplicaciones con agentes IA para operaciones multi-isla, el orden correcto es: el agente ve, propone y registra; un humano revisa; solo después escribe. Lo mismo aplica si construyes sobre desarrollo de apps para móviles en Mallorca o un software a medida en Palma: la sombra es un producto, no un «luego lo miramos».
Demo, sombra y producción
Estas tres etapas no son marketing. Son niveles de riesgo distintos cuando un huésped en Ibiza escribe por WhatsApp a las 22:00 y tu HQ está en Palma.
| Etapa | Qué hace el agente | Riesgo para huéspedes / ops | Cuándo encaja en temporada (Baleares) | Qué mides |
|---|---|---|---|---|
| Demo | Responde en sandbox con datos ficticios o grabados. | Casi nulo (nadie real recibe nada). | Invierno / pretemporada: validar UX y prompts. | ¿Entiende el flujo? ¿Alucina en casos inventados? |
| Sombra (dry-run) | Lee tráfico real (o réplica) y propone acciones; no escribe a clientes ni CRM. | Bajo si los logs están aislados; medio si filtras datos personales mal. | Pre-pico y hombro de temporada: aprende ferry, idiomas y picos de Ibiza/Menorca sin tocar reservas. | % propuestas correctas, tiempo hasta revisión humana, falsos positivos por isla. |
| Producción | Ejecuta escrituras permitidas (mensaje, ticket, nota CRM) bajo matriz de permisos. | Alto si la sombra fue corta o sin revisor. | Solo cuando la sombra es «aburrida»: errores raros y reglas claras por isla. | Errores en producción, escalados, tiempo de recuperación, NPS interno ops. |
Si tu mapa de tareas aún mezcla humano y agente sin fronteras claras, revisa antes el enfoque de humano, agente o híbrido. La sombra no sustituye ese mapa: lo prueba con datos reales.
Matriz de permisos del agente
Antes de activar escritura, fija qué puede leer, qué puede proponer y qué no debe tocar nunca. En temporada alta balear, «nunca» suele incluir precios dinámicos y datos personales sensibles sin supervisión.
| Sistema / dato | Lectura | Escritura (propuesta → luego real) | Nunca |
|---|---|---|---|
| CRM | Fichas, historial, estado del lead/reserva. | Notas, etiquetas, ficha de handoff; escritura real solo tras sombra estable. | Borrar contactos, fusionar fichas sin regla humana. |
| WhatsApp / email | Hilos entrantes (con retención y acceso controlado). | Borradores de respuesta; envío real con umbral y revisión. | Promesas de descuento, datos médicos, amenazas legales automáticas. |
| PMS / tickets | Disponibilidad, estados de limpieza, tickets abiertos. | Crear ticket borrador; cambiar estado solo en producción con reglas. | Cerrar turnos o marcar limpiezas «hechas» sin sensor/humano. |
| Pricing | Tarifas publicadas, reglas de temporada. | Sugerir rangos en sombra; nunca aplicar solo en pico. | Cambiar precio en vivo sin doble OK (ops + revenue). |
| Datos personales | Mínimo necesario para la tarea (minimización). | Solo campos previstos en la ficha; log de sombra anonimizado cuando se pueda. | Exportar listados, entrenar con PII sin base legal, compartir entre islas sin necesidad. |
Una buena sombra también deja claro qué debe escribir el agente en el CRM cuando llegue el humano: la ficha de handoff se puede entrenar en dry-run sin molestar a nadie. Si tu CRM aún no está listo, haz antes una auditoría rápida del CRM para agentes IA.
Tres fallos típicos de la semana 1
No son checklists de sí/no. Son errores que vemos (y evitamos) cuando el modo sombra se trata como un interruptor, no como un proceso.
- Sombra sin revisor humano. El agente llena logs; nadie los lee. En Palma el HQ cree que «ya está aprendiendo», pero nadie marca falsos positivos. Resultado: en la semana 3 activáis escritura con la misma tasa de error. Asigna un revisor por franja (mañana/tarde) y un cupo diario de propuestas a revisar.
- El agente propone sin contexto ferry / isla. Una propuesta «envía técnico ya» desde Menorca ignora el siguiente ferry; en Ibiza ignora que el pico de check-ins satura limpiezas. Metadatos de isla, lead time y calendario de temporada deben entrar en el prompt y en las reglas — no solo el texto del WhatsApp.
- Pasar a escritura demasiado pronto. Dos días de demo + un viernes de sombra no bastan. Si el canal duele (a menudo WhatsApp), mapea cuellos de botella antes: el mapa de cuellos de botella de WhatsApp evita que el agente herede un proceso roto. Criterio práctico: producción solo cuando la sombra sea aburrida — mismas excepciones, pocas sorpresas.
FAQ
¿Cuánto debe durar el modo sombra?
Depende del volumen. En ops multi-isla suele bastar un bloque continuo de 10–14 días con tráfico real de al menos dos islas (por ejemplo Palma + Ibiza). Si Menorca tiene menos volumen, alarga hasta cubrir picos de fin de semana.
¿La sombra usa datos reales de clientes?
Sí, o una réplica con el mismo tráfico. Por eso la matriz de permisos y la minimización de PII importan desde el día 1. Los logs de revisión pueden anonimizarse para formación interna sin perder la señal operativa.
¿Puedo hacer sombra solo en una app web y luego pasar a móvil?
Sí, si el agente consume los mismos eventos. Si el equipo de campo vive en el móvil, prueba también ahí: elige bien entre nativa, híbrida o web app según cobertura y offline en Menorca/Ibiza.
¿Quién decide el paso a producción?
No el modelo. Un responsable de ops (o producto) con la matriz de permisos firmada y un umbral de error acordado. Marketing y web pueden esperar: el diseño web en Mallorca y el marketing online en Mallorca no sustituyen el OK de quien paga el error en temporada.
Caso: 14 días de sombra multi-isla
Imagina una app de campo para equipos de limpieza y mantenimiento con HQ en Palma. El agente propuesto debe: leer tickets y mensajes, sugerir prioridad, redactar la nota de handoff y —más adelante— crear el ticket. Durante 14 días corre en sombra.
Día 1–3: el agente ve el tráfico de Palma e Ibiza. Propone prioridades; un coordinador en Palma marca acierto/error en un panel. Descubre que «urgente» en Ibiza a las 21:00 suele ser llave / acceso, no avería eléctrica. Ajustan reglas.
Día 4–7: entra Menorca. La conectividad de campo falla a ratos; el agente empieza a proponer reintentos agresivos de WhatsApp. El revisor corta esa regla: mejor cola local y sync cuando hay red. Sin sombra, eso habría spameado a propietarios.
Día 8–11: el agente ya acierta en ~el patrón estable de propuestas (esto es ilustrativo, no una métrica prometida). Las excepciones se agrupan: ferry, idioma del huésped, apartamento sin Wi‑Fi. Se documentan en la matriz.
Día 12–14: la sombra es aburrida. Mismas excepciones, pocos falsos positivos nuevos. Solo entonces habilitan escritura de tickets borrador — no mensajes a clientes. Los mensajes siguen en borrador humano. Ese es el salto controlado a producción: no «el agente ya habla solo».
Checklist de 14 días
- Definir alcance: qué eventos lee el agente (CRM, WhatsApp, PMS) y en qué islas.
- Publicar la matriz read / write / never y quién la firma.
- Nombrar revisores humanos por franja y cupo diario de propuestas.
- Registrar metadatos de isla, ferry/lead time e idioma en cada propuesta.
- Anonimizar o minimizar PII en logs de formación.
- Correr al menos un fin de semana de pico relativo (Ibiza o Palma) dentro de la ventana.
- Incluir un día con mala conectividad (Menorca o campo) para ver reintentos.
- Congelar prompts/reglas 48 h antes de valorar el paso a escritura.
- Activar primero escrituras de bajo impacto (nota CRM / ticket borrador), no canal cliente.
- Acordar criterio de «sombra aburrida» antes de celebrar el go-live.
Pásanos a producción solo cuando la sombra sea aburrida. Si quieres que revisemos el diseño del dry-run en tu app, envíanos 3 ejemplos anonimizados de logs de sombra (propuesta + contexto de isla) y dinos qué isla os duele más ahora mismo. En Derek Solutions — diseño web, apps y marketing en Mallorca — respondemos en derek@dereksolutions.com · +34 680 283 973.
