Una demo en un espacio de ocio debe comprobar una tarea aprobada en un recinto concreto; no certifica seguridad, navegación, privacidad, integración con TPV, autonomía, mantenimiento, continuidad, servicio, plantilla o retorno. El comportamiento de un robot depende del modelo, versión, configuración, entorno, público, proceso, datos, infraestructura y contrato.
Antes de probar, defina tarea, zona, horario, carga, responsable, personas participantes, datos, interfaces, criterio de parada y alternativa manual. Las decisiones sobre seguridad, emergencias, acceso, huéspedes, alimentos, personal y operaciones pertenecen al operador y a los responsables competentes. Este artículo no proporciona instrucciones de emergencia ni certifica un producto o proceso.
Alcance y entorno de la demo
Documente superficie, luz, mobiliario, rutas, puertas, carga, puntos de relevo, red, energía, base, ruido, zonas excluidas, afluencia y condiciones variables. No debe asumirse que el modelo dispone de LiDAR, cámaras, IMU, geofencing, señales, parada, replanificación o una respuesta determinada ante el público. Solicite al proveedor la documentación de las funciones, límites, mantenimiento, actualizaciones, soporte y modo de fallo.
NIST indica que el desempeño de un sistema robótico debe validarse y caracterizarse para la aplicación y entorno previstos, con métricas contextualizadas.1 No se debe intentar simular riesgos o contactos fuera de los procedimientos aprobados por el recinto. Defina qué evento suspende la demo, quién interviene y cómo se recupera manualmente la tarea.
Personas, servicio y proceso
La presencia de visitantes, personal y operaciones simultáneas requiere procedimientos autorizados por el espacio. No suponga que el robot detectará cualquier obstáculo, reducirá velocidad, evitará bloqueos, mejorará la experiencia o disminuirá tiempos de sala. Si se evalúa un robot camarero, defina origen, destino, carga, punto de relevo, tarea manual, responsable y contingencia.
HSE recomienda cambios por fases, consulta con las personas afectadas, responsabilidades identificadas, formación y supervisión.2 Esto permite organizar el ensayo, pero no demuestra aceptación, interfaz intuitiva, productividad, calidad de servicio, salud o decisiones de plantilla. Si se mide carga física, NIOSH recomienda registrar tareas, trayectos, pesos, posturas, pausas e incidencias en condiciones comparables.3
TPV, datos e integración
La conexión con TPV, comandas, barra, cocina, inventario, mesa, aplicación o gestión de sala debe tener un alcance explícito. Pregunte qué API, permisos, funciones, datos, actualizaciones, registros, soporte y tareas manuales incluye la oferta. No suponga que se generará una orden, que se sincronizará inventario, que se confirmará una entrega o que se reducirá trabajo administrativo.
El RGPD regula información personal identificada o identificable.4 Pedidos, mesas, cámaras, posiciones, usuarios o registros pueden requerir finalidad, minimización, acceso, conservación y obligaciones aplicables. No se debe prometer integración segura, sincronización, trazabilidad o privacidad por la presencia de una API.
NIST SP 800-82 Rev. 3 propone gestionar tecnología operativa considerando rendimiento, fiabilidad y seguridad, amenazas, vulnerabilidades y contramedidas.5 La guía no certifica TPV, red, APIs, sensores, firmware, copias de seguridad, flotas o productos concretos.
Energía, mantenimiento y soporte
La batería, recarga, retorno a base, base de carga, actualización, mantenimiento, diagnóstico, sustitución y soporte deben confirmarse por modelo, configuración y contrato. No fije duración de batería, tiempo de recarga, número de pedidos, latencia, distancia, respuesta o disponibilidad como estándares universales. Registre durante la demo energía, ciclos, intervención, mantenimiento, soporte, incidencias y condiciones no medidas.
Solicite por escrito alcance de soporte, horario, canales, SLA si existe, piezas, desplazamientos, actualizaciones, exclusiones y costes. Una demostración no prueba que el mantenimiento sea autónomo, que una actualización funcione en el recinto o que la operación sea rentable.
| Área de evaluación | Pregunta y evidencia a solicitar | Prueba acotada | Criterio de decisión |
|---|---|---|---|
| Entorno y navegación | Modelo, versión, funciones declaradas, rutas, superficie, luz, carga, red, zonas excluidas y modo de fallo. | Una tarea, zona y franja aprobadas. | Resultado observado; no seguridad o replanificación garantizadas. |
| Personas y proceso | Roles, formación, tareas manuales, punto de relevo, comunicación, contingencia y responsables. | Personal designado bajo supervisión. | Dudas, incidencias y ajustes necesarios; no aceptación o plantilla predeterminadas. |
| TPV, datos e integración | APIs, permisos, datos mínimos, accesos, registros, actualizaciones y funciones manuales. | Configuración mínima para la tarea autorizada. | Riesgos y autorizaciones revisados antes de integrar o ampliar. |
| Energía y soporte | Base, alimentación, carga, mantenimiento, contrato, soporte, repuestos y exclusiones. | Ciclo de trabajo definido por el recinto. | Interrupciones y asistencia observadas; no autonomía o continuidad asumidas. |
| Resultados observados | Línea base, ciclos, intervención, incidencias, costes y condiciones de prueba. | Comparación definida por el operador. | Ajustar, repetir, limitar, ampliar bajo condiciones o detener. |
La matriz no certifica un modelo, TPV, recinto o contrato. Organiza la evidencia necesaria para una decisión local.
Recurso operativo
- 01Ventana entre sesiones
- 02Ruta de servicio
- 03Limpieza o entrega
- 04Preparación siguiente pase
Las transiciones entre sesiones suelen concentrar la oportunidad de automatización.
Qué aporta
Permite evaluar una tarea de ocio con evidencia de recinto, modelo, proceso y soporte
Hace visibles dependencias de público, datos, TPV, energía, mantenimiento y responsables
Aporta un registro para ajustar, repetir, limitar, ampliar bajo condiciones o detener una demo
Qué revisar
Requiere documentación de proveedor, autorización del recinto, formación, supervisión y alternativa manual
Necesita revisión de datos, procesos, red, soporte y condiciones del contrato
Una demo favorable no garantiza seguridad, privacidad, integración, autonomía, servicio, mantenimiento, plantilla, ahorro o retorno
De la demo a la prueba por recinto
Una demo reúne evidencia de un modelo, una tarea y unas condiciones; no autoriza por sí sola un despliegue. Tras registrar respuestas del proveedor, responsables, datos, incidencias y límites, aplique el checklist de limpieza en cines y teatros cuando el caso se centre en una sala, o el diseño de recorridos en espacios de ocio cuando deba compararse una ruta por zona y franja.
Con evidencia local, contrato, autorizaciones y límites observados, el recinto puede ajustar, repetir, limitar, ampliar bajo condiciones o detener el caso de uso.
Fuentes y alcance
¿Quieres identificar el siguiente proceso que puedes automatizar?
En una primera conversación revisamos el trabajo repetitivo, los cuellos de botella y la solución que mejor encaja en tu operación.
