Cómo definir SLO de red y modos seguros para un workflow de physical AI antes de conectar robots a private 5G

Paso 1 — Dibuja el loop físico y separa información de control. Lista sensores, preprocesamiento, inferencia, planificación, red, actuadores y supervisión humana. Marca qué mensajes solo informan y cuáles pueden producir movimiento o modificar una máquina. Para cada efecto físico, identifica la última señal necesaria y el tiempo máximo durante el cual sigue siendo válida. No empieces comprando una red “ultra low latency”; empieza entendiendo qué deadline necesita el proceso. Esta descomposición también ayuda a decidir qué datos deben quedarse on-premise, qué parte puede ir al edge y qué análisis puede viajar a nube sin participar en un control inmediato.

Paso 2 — Asigna un budget end-to-end y repártelo entre etapas. Si una decisión debe completarse en cien milisegundos, reserva margen para sensor, serialización, red, cola de cómputo, inferencia, postprocesamiento y comando. No utilices el promedio como presupuesto. Define percentiles y jitter máximos, además de pérdida de paquetes. Cada componente recibe un límite y telemetría sincronizada. Si una actualización de modelo consume más tiempo, el sistema puede compensar en otra etapa o rechazar la configuración. La arquitectura debe saber cuándo un modelo “mejor” deja de ser válido porque ya no cabe dentro de la ventana segura del workflow.

Paso 3 — Define modos degradados antes de probar producción. Para cada incumplimiento relevante —pérdida de enlace, congestión, edge caído, sensor inválido, inferencia tardía— escribe la respuesta esperada. Puede ser detener movimiento, reducir velocidad, pasar a control local determinista, mantener último estado solo durante una ventana muy corta o pedir intervención. Estas decisiones pertenecen a ingeniería de seguridad y al dominio físico; un modelo de lenguaje no debe improvisarlas. Versiona la tabla de fallbacks y hazla parte del sistema de control. La autonomía solo se habilita cuando existe una salida segura y conocida para cada pérdida de condición crítica.

Paso 4 — Instrumenta trazas con un clock consistente. Registra timestamps de percepción, envío, recepción, inicio y fin de inferencia, comando y confirmación. Usa IDs de ciclo para unir eventos sin depender del orden del log. Añade versión de modelo, nodo edge y calidad de señal. Con esos datos calcula P50, P95, P99, jitter, drop rate y porcentaje de deadlines incumplidas. No necesitas capturar video completo para cada run si eso crea problemas de privacidad o almacenamiento; conserva metadatos suficientes y muestras controladas. La observabilidad debe permitir explicar una degradación sin reconstruir todo desde memoria humana.

Paso 5 — Ejecuta fault injection en un entorno controlado. Simula latencia, pérdida de paquetes, reinicio de edge y degradación de sensores con procedimientos seguros y límites físicos. Comprueba que el sistema entra al modo previsto, que no acumula comandos viejos y que recupera control de forma definida. Repite con diferentes cargas de red y cómputo. Cada prueba produce evidencia y una lista de fallos. No busques simplemente “que no pase nada malo”; valida condiciones específicas. Cuando una prueba falla, corrige diseño y vuelve a ejecutar el mismo escenario para demostrar que la protección realmente cambió.

Paso 6 — Crea un physical AI readiness receipt antes de escalar. Resume loops críticos, deadlines, SLO alcanzados, modos seguros, pruebas ejecutadas, incidencias abiertas y versión aprobada del stack. En Goatify, podemos usar este formato como servicio de assessment para fabricantes, logística o instalaciones con robots. Nuestro papel puede concentrarse en orquestación y evidencia, sin reemplazar controladores certificados o sistemas de seguridad especializados. La venta es concreta: antes de conectar más inteligencia, mostramos qué depende de red, qué debe permanecer local y qué ocurre cuando una condición desaparece. Esa claridad reduce riesgo y orienta inversión en edge, conectividad y observabilidad.