Autonomía auditable

Una parte de la conversación sobre robótica trata de capacidad: cuánto levanta un sistema, qué tan lejos vuela, cuánto tiempo opera. Para eso tenemos especificaciones. Pero no es la conversación que decide si una empresa despliega.

La conversación que decide trata de responsabilidad. Cuando un sistema actúa dentro de una planta, un puerto o un hotel: quién lo autorizó, qué decidió, por qué y qué pasó como consecuencia. Si esas preguntas no se pueden responder después, con precisión y rápido, el sistema no entra en producción por muy capaz que sea.

Por eso decimos que el producto no es la autonomía. Es la autonomía auditable.

Cada decisión es un registro

Cada sistema Hivora, desde una cerradura hasta un humanoide, produce un registro por cada decisión en la que participa. No una línea de log: un registro con forma. Dice qué identidad solicitó la acción, qué dispositivo la ejecutó, qué autorización recibió, en qué entradas se basó, cuál fue el resultado y cuándo ocurrió cada paso. En los sistemas autónomos, Hivora Hive agrega el contexto de la misión: qué se le pidió al sistema, qué plan eligió y qué verificaciones de seguridad se evaluaron en el camino.

Esos registros van a Vectry, el mismo registro que guarda cada apertura de puerta, cada pago y cada lectura de sensor de tu operación. Una revisión de incidente, una auditoría de cumplimiento o una pregunta sencilla de un gerente se resuelven contra una sola fuente.

Es una restricción de diseño: un sistema que no puede producir el registro no ejecuta la acción.

Supervisada, no desatendida

La autonomía en nuestros sistemas está acotada por diseño. Hivora Hive planifica misiones y arbitra la seguridad en tiempo real, pero los límites dentro de los que lo hace los fijan personas: dónde puede operar un sistema, qué puede hacer ahí, qué condiciones lo obligan a detenerse y quién puede intervenir.

Un operador puede observar cualquier sistema, interrumpir cualquier misión y sacar cualquier unidad de servicio en cualquier momento. Cuando un sistema se encuentra con una situación que su misión no previó, no improvisa. Se detiene, reporta y espera a una persona. Cualquiera que haya operado un sitio industrial reconocerá ahí una virtud.

El sistema también sabe para quién trabaja. Cada unidad tiene una identidad conocida, cada misión se autoriza a través de Veripass y nada actúa en un sitio de forma anónima. Una orden que no viene de una identidad reconocida no es una orden.

Parada segura garantizada

Cada sistema Hivora tiene un estado seguro y tiene garantizado llegar a él: por orden de un operador, por pérdida de comunicación con Core, por cualquier condición de seguridad que no pueda resolver por sí mismo, o desde un botón físico de parada donde la plataforma lo tiene.

En un dispositivo fijo el estado seguro es simple: una cerradura se mantiene cerrada, un ascensor ignora solicitudes de piso no autorizadas, un gateway conserva las últimas reglas conocidas. En un sistema que se mueve es más difícil, y ahí se concentra buena parte del esfuerzo de ingeniería del programa de robótica: un humanoide debe detenerse sin soltar lo que carga sobre una persona, una plataforma aérea debe aterrizar o sostenerse sin poner en riesgo a nadie abajo, un vehículo terrestre debe frenar y sostenerse en una pendiente. La parada segura se ejercita de forma rutinaria, para que funcione cuando la situación no sea rutina.

Los datos se quedan donde diga tu política

Estos registros describen tu operación con detalle. Dónde viven es decisión tuya, no nuestra.

Los sistemas Hivora operan con el plano de control en la nube o en tus instalaciones, y la telemetría y los datos de eventos residen en la región que tu política exija. En sitios que no pueden depender de la conectividad, Hivora Edge conserva identidades, reglas y registros de forma local y concilia cuando vuelve la conexión. Nada en la forma en que funcionan los sistemas asume que tus datos salen de tu jurisdicción.

Los estándares contra los que diseñamos

Diseñamos y probamos contra los estándares a los que se someten nuestros sectores, y los tratamos como insumos de ingeniería y no como una lista de verificación.

• ISO 10218 e ISO 13482 para seguridad de robots, cubriendo sistemas industriales y sistemas que operan junto a personas.
• SORA y EASA como marcos para operación aérea más allá de la línea visual.
• SOC 2 Type II para el manejo de datos y telemetría.
• GDPR e ISO 27001 para privacidad y seguridad de la información.

La certificación es una conversación por despliegue, porque depende del sitio, del sector y de la jurisdicción. Lo que se cumple en todos los casos es que los sistemas se construyeron con estos marcos delante de los ingenieros, y que el registro que producen es la evidencia que un evaluador va a pedir.

Por qué la auditabilidad es el producto

Un gerente de operaciones necesita saber qué hizo un sistema en el turno de noche. Una aseguradora necesita saber cómo se detiene. Un regulador necesita saber quién lo autorizó. Un responsable de seguridad necesita reconstruir un incidente al segundo. Un cliente necesita saber que sus datos no salieron del país.

Cada una de esas es una pregunta sobre el registro, que es lo que nuestros sistemas están hechos para producir. La capacidad determina qué puede hacer un sistema. La auditabilidad determina si alguien lo va a permitir.

Si tu operación necesita responder esas preguntas, solicita acceso. Trabajamos con un grupo selecto de socios y cada relación empieza como un piloto acotado.