Seguridad y gobierno
Un robot con credencialeses un usuario más.
Automatizar significa dar accesos a un proceso que corre solo. La pregunta de TI no es si funciona: es quién puede tocarlo, con qué permisos y cómo se comprueba después.
Seguridad y gobierno
Un robot con credenciales es un usuario más. Trátalo como tal.
Automatizar significa dar accesos a un proceso que corre solo. La pregunta de TI no es si funciona: es quién puede tocarlo, con qué permisos y cómo se comprueba después.
Accesos por rol
Quién construye, quién publica, quién ejecuta y quién solo consulta son cuatro permisos distintos. La separación es del sistema, no del acuerdo verbal.
- Perfiles diferenciados por función
- Permisos a nivel proyecto y proceso
- Alta y baja de usuarios administrada
Gestión de credenciales
Las credenciales que usa un robot se administran en la plataforma y se referencian desde el flujo. No se escriben dentro del proceso ni viajan en un archivo.
- Almacenamiento centralizado
- Referencia por nombre, no por valor
- Rotación sin reescribir el proceso
Separación de entornos
Desarrollo, pruebas y producción son ambientes distintos con agentes distintos. Un proceso llega a producción cuando se publica, no cuando alguien lo guarda.
- Agentes asignados por entorno
- Publicación como paso explícito
- Borrador y versión publicada separadas
Auditoría y trazabilidad
Cada ejecución deja constancia: qué proceso corrió, en qué agente, a qué hora, con qué parámetros y con qué resultado. Es la respuesta a la pregunta del auditor.
- Bitácora por ejecución
- Registro de cambios en el proceso
- Evidencia exportable por periodo
Monitoreo y alertas
Un proceso desatendido necesita vigilancia activa. Si un agente se cae o una ejecución se sale de su ventana, alguien tiene que enterarse.
- Estado de agentes en tiempo real
- Alertas por falla y por excepción
- Umbrales de duración por proceso
Control de la ejecución
Un proceso se puede detener, pausar o despublicar. La capacidad de frenar algo en producción es parte del control, no una función de emergencia.
- Detener ejecución en curso
- Despublicar para bloquear nuevas corridas
- Reintentos con política definida
Sobre dónde vive el dato
El plano de control es nube Pynbot: diseño, orquestación, permisos y bitácora. La ejecución ocurre en agentes dentro de tu red, operando tus aplicaciones con tus accesos. Para ejecutar un proceso, el dato de negocio no necesita salir del sistema donde ya está.
Infraestructura
La arquitectura se adapta a la tuya, no al revés.
Pynbot separa el plano de control del plano de ejecución. Esa separación es lo que permite que el diseño y la orquestación vivan en la nube mientras los procesos corren dentro de tu perímetro, sobre tus sistemas y con tus accesos.
Nube Pynbot
Tu perímetro
- NavegadorPersonasQuien diseña, quien publica, quien opera y quien sólo consulta. Cada uno con su rol.
- Acceso por HTTPS
- Permiso por proyecto y proceso
- Nube PynbotPlano de controlPlayground, Hub y Vision. Diseño, orquestación, credenciales, permisos y bitácora.
- Actualización continua
- Sin servidores que instalar
- Bitácora por ejecución
- Tu redRunnersLos agentes que ejecutan. Se instalan en las máquinas que tú decidas y toman trabajo del plano de control.
- Agentes por entorno y por área
- Estado en tiempo real
- Sin límite en el esquema actual
- Tu perímetroTus sistemasERP, bases de datos, portales, correo y escritorio. El robot los opera como lo haría la persona.
- Mismos accesos que un usuario
- El dato no sale para ejecutarse
Las dos primeras capas son nube Pynbot · las dos últimas, tu perímetro
Por qué los runners cambian la conversación con TI
Un runner es un agente instalado en una máquina tuya. Recibe del plano de control qué proceso corresponde correr y lo ejecuta ahí mismo, contra las aplicaciones que ya tienes. La consecuencia práctica es que el dato de negocio no necesita viajar a la nube para que el proceso funcione: lo que sube es la información de orquestación —qué corrió, cuándo, en qué agente y con qué resultado—, no el contenido que el proceso manipula.
Ejecución cerca del sistema
Un proceso que toca un ERP interno puede correr en un runner dentro de esa misma red, sin abrir el sistema al exterior.
Segmentación por entorno
Desarrollo, pruebas y producción con agentes distintos. Un borrador no puede tocar producción por accidente.
Distribución por área
Agentes separados por área o por planta, para que el alcance de cada uno sea el que su función necesita.
Visibilidad del estado
Qué agente está en línea, cuál está ocupado y cuál dejó de responder, en tiempo real.
Sobre qué se despliega
La infraestructura de Pynbot puede operar sobre distintos proveedores según los requerimientos técnicos y operativos de cada organización. No son partners ni certificadores: son la nube sobre la que se levanta el despliegue.
- AWSAmazon Web Services
- Microsoft Azurenube de Microsoft
- Vultrinfraestructura dedicada
Si tu organización tiene una política de infraestructura que exige un proveedor concreto, una región concreta o un modelo distinto, se revisa caso por caso con el equipo técnico antes de cualquier compromiso.
Arquitectura
Control en la nube. Ejecución donde vive tu operación.
Pynbot está diseñado como Pure Cloud: la plataforma de administración se actualiza de forma continua, sin ventanas de mantenimiento para el cliente. La ejecución es otra cosa: ocurre en agentes instalados en las máquinas que tú decidas.
- Nube Pynbot
Plano de control
Playground, Hub y Vision. Diseño, orquestación, credenciales, permisos y bitácora.
- Actualizaciones continuas
- Sin instalación de servidores
- Acceso por rol
- Tu red
Plano de ejecución
Agentes que corren los procesos sobre tus aplicaciones, con tus accesos y dentro de tu perímetro.
- El dato de negocio no sale del sistema origen para ejecutarse
- Agentes por entorno y por área
- Sin límite de runners en el esquema comercial actual
Si tu arquitectura exige un modelo distinto, lo revisamos caso por caso con el equipo técnico.
Protección de la información
Qué protege la plataforma y qué decide tu despliegue.
Separar las dos cosas es más útil que una lista de garantías. Lo de la izquierda es propiedad del producto; lo de la derecha se define contigo al implementar, y por eso no se promete de antemano.
Lo que la plataforma implementa
Tránsito cifrado y forzado
El acceso al plano de control es exclusivamente por HTTPS. El puerto sin cifrar redirige de forma permanente y el dominio anuncia HSTS con vigencia de un año, incluidos subdominios.
Comprobable desde fuera con cualquier analizador de TLS
Credenciales por referencia
Las credenciales se administran en la plataforma y el flujo las invoca por nombre. La definición del proceso nunca contiene el valor, así que rotar una credencial no obliga a reescribir el proceso.
Capacidad del producto
Autorización por rol y alcance
Construir, publicar, ejecutar y consultar son cuatro permisos distintos, aplicables a nivel de proyecto y de proceso. El mínimo privilegio se configura, no se acuerda de palabra.
Capacidad del producto
Trazabilidad por ejecución
Cada corrida deja qué proceso fue, en qué agente, a qué hora, con qué parámetros y con qué resultado. Los cambios al proceso quedan registrados y publicar es un paso explícito con usuario y fecha.
Capacidad del producto
Aislamiento de la ejecución
Cada organización opera sus propios runners, dentro de su propia red y con sus propias credenciales. La ejecución de un cliente no comparte máquina con la de otro.
Consecuencia de la arquitectura
Control sobre lo que está corriendo
Una ejecución se puede detener en curso y un proceso se puede despublicar para bloquear nuevas corridas. Poder frenar algo en producción es parte del control, no una función de emergencia.
Capacidad del producto
Lo que define tu despliegue
Estas decisiones se toman con tu equipo al implementar, porque dependen de tu política interna y del proveedor sobre el que se levante la infraestructura. Enunciarlas como garantía general sería inexacto.
Proveedor y región de la nube
AWS, Azure o Vultr, con la región que tu política exija.
Cifrado en reposo
Según lo que contemple la arquitectura implementada y los servicios del proveedor elegido.
Respaldos y su periodicidad
Alcance, frecuencia y retención se definen con el área responsable.
Residencia del dato
Dónde vive cada pieza depende del modelo acordado y del proveedor.
Integración con tu identidad
Cómo se alinean usuarios y permisos con tus políticas internas se revisa en la implementación.
Requisitos regulatorios
Si operas bajo un marco específico, se revisa antes de comprometer nada.
IA y datos empresariales
IA empresarial sin perder el control de tus datos.
Pynbot puede usar modelos de OpenAI y de Anthropic dentro de un proceso. Conviene decir con precisión qué implica eso, porque la respuesta cómoda —«tus datos nunca salen»— sería falsa en cuanto un proceso llama a una API externa.
La IA es un bloque, no la plataforma
Un proceso usa un modelo sólo donde el flujo lo incluye explícitamente. Un proceso sin bloques de IA no envía nada a ningún proveedor de modelos.
Lo que sale es lo que el bloque manda
Cuando un paso llama a un modelo externo, viaja el contenido que ese paso le pasa. Ni más, ni el resto del proceso. El alcance se decide al construir el flujo.
Se puede acotar o evitar
Si un proceso trata información que no debe salir del perímetro, esa parte se resuelve con bloques determinísticos y la IA queda fuera de ese tramo.
Queda registrado como cualquier paso
Una llamada a un modelo es un paso del proceso, y como tal aparece en la bitácora de la ejecución.
El criterio que aplicamos al diseñar: la IA resuelve la parte ambigua de un proceso, no lo gobierna. Decidir qué información puede salir hacia un proveedor externo es una decisión de negocio, se toma al construir el flujo y se documenta.
Pynbot Vision
La capa de datos, bajo los mismos controles.
Vision lee de tu ERP, tu CRM, tus bases y tus archivos para construir indicadores. No es un producto aparte con su propio modelo de seguridad: usa la identidad, los roles, las credenciales y la bitácora de la misma plataforma.
Control de acceso y roles
Vision no tiene padrón de usuarios propio. Se entra con la cuenta de la plataforma y con el rol que ya se tiene; ver un tablero es un permiso más, no un acceso paralelo.
Respeta los permisos del origen
La conexión a cada fuente opera con las credenciales que se le asignan, y por tanto con el alcance que esa cuenta ya tiene en el sistema origen. Vision no ve más de lo que esa conexión puede ver.
Conexiones y credenciales
Las credenciales de cada origen se administran centralizadas y se invocan por referencia, igual que en cualquier proceso. La definición de un tablero no contiene la cadena de conexión.
Aislamiento entre clientes
La información de cada organización se mantiene separada de la de cualquier otra. Ni los orígenes, ni las credenciales, ni los tableros de un cliente son visibles desde otro.
Cifrado en tránsito
El acceso a Vision ocurre exclusivamente sobre HTTPS, con redirección permanente desde el puerto sin cifrar y HSTS anunciado a un año. El cifrado en reposo se define según la infraestructura sobre la que se implemente.
Trazabilidad y auditoría
Las ejecuciones que alimentan a Vision dejan la misma constancia que cualquier otra: qué corrió, cuándo, sobre qué origen y con qué resultado. La evidencia se exporta por periodo.
La IA no amplía permisos
Preguntarle a los datos en lenguaje natural no abre una puerta nueva. La capa conversacional responde dentro del alcance que esa persona ya tiene: si no puede ver un tablero, tampoco puede preguntarle.
La IA consulta sólo lo autorizado
La consulta se resuelve contra la información a la que ese usuario está autorizado, no contra el conjunto completo. El permiso es la frontera, en la conversación igual que en la pantalla.
Lectura, no escritura
Vision consulta los orígenes para construir indicadores. Escribir de vuelta en un sistema es trabajo de un proceso automatizado, con su publicación y su bitácora, no de un tablero.
Sobre qué se implementa
La arquitectura de Vision puede levantarse sobre AWS, Microsoft Azure o Vultr según las necesidades del proyecto, igual que el resto de la plataforma. Dónde reside cada modelo de datos y si la agregación debe ocurrir dentro de tu perímetro son decisiones de arquitectura que se toman en la implementación, no supuestos de una página web.
Un robot opera el sistema donde el dato ya está. Un tablero tiene que leerlo para poder sumarlo. Son dos capas con necesidades distintas, y por eso los controles de Vision se enuncian aparte en lugar de dar por buena la respuesta de la automatización.
Privacidad y control
Las preguntas que hace TI antes de aprobar.
Respondidas según lo que el producto hace hoy. Donde la respuesta depende de la implementación, lo dice en lugar de dar una garantía general.
¿Dónde pueden residir mis datos?
El dato de negocio se queda donde ya está: el proceso corre en un runner dentro de tu red y opera tus sistemas ahí mismo. Al plano de control sube información de orquestación —qué proceso corrió, cuándo, en qué agente y con qué resultado—. La residencia de esa capa depende del proveedor y la región sobre los que se despliegue la infraestructura, y se define contigo.
¿Quién puede acceder a ellos?
Dentro de tu organización, quien tenga el rol que lo permita: construir, publicar, ejecutar y consultar son permisos distintos, aplicables por proyecto y por proceso. Los runners operan con las credenciales que tú les asignas, que son las del usuario que hoy haría ese trabajo.
¿Cómo se protegen las credenciales?
Se administran de forma centralizada en la plataforma y el flujo las invoca por referencia. El proceso nunca contiene el valor en su definición, así que ni viaja en un archivo ni queda escrito dentro del flujo. Rotar una credencial no obliga a tocar el proceso.
¿Qué información necesita Pynbot?
Para orquestar: qué procesos existen, en qué agentes deben correr y cuándo. Para ejecutar: las credenciales de los sistemas que el proceso opera, guardadas como se describe arriba. El contenido que el proceso manipula no necesita salir del sistema de origen.
¿Qué ocurre con la información que procesa un robot?
Se queda en el ámbito donde el proceso la trabaja: el runner la lee del sistema origen y la escribe donde el flujo indique. Si un paso concreto llama a un servicio externo —una API o un modelo de IA—, ese paso sí envía lo que se le pase, y eso se decide al construir el flujo.
¿Cómo se auditan las ejecuciones?
Cada ejecución deja constancia de proceso, agente, hora, parámetros y resultado, y la evidencia se puede exportar por periodo. Los cambios al proceso quedan registrados y la publicación es un paso explícito con su usuario y su fecha: un proceso en producción no cambia porque alguien editó un borrador.
¿Cómo se manejan distintos usuarios y permisos?
Con perfiles diferenciados por función y permisos a nivel de proyecto y de proceso. El alta y la baja de usuarios se administra desde la plataforma, de modo que retirar el acceso a alguien es una acción, no una revisión manual de configuraciones.
¿Y si mi organización tiene políticas de infraestructura estrictas?
Se revisa antes de comprometer nada. La separación entre plano de control y plano de ejecución da margen para adaptarse —dónde viven los runners, sobre qué nube se levanta la infraestructura, qué región—, pero cualquier escenario que se salga de ese modelo se evalúa caso por caso con el equipo técnico en lugar de darse por hecho en una página web.
SLA de soporte
Tiempos comprometidos, por severidad.
Estándar para clientes con licenciamiento activo y soporte vigente. Aplica igual a Pynbot Automation y a Pynbot Vision: es una sola plataforma y un solo canal de atención.
| Severidad | Ejemplo | Primera respuesta | Objetivo de restauración | Cobertura |
|---|---|---|---|---|
| CríticaSeveridad 1 | Plataforma productiva no disponible, varios procesos críticos detenidos, imposibilidad general de ejecutar automatizaciones, o indisponibilidad de Vision que afecte una operación crítica.El diagnóstico inicia de inmediato después de la primera respuesta. | 1 horamáximo | 4 horasobjetivo de workaround o restauración, cuando está bajo control de Pynbot | 24/7incidentes críticos en ambientes productivos identificados previamente |
| AltaSeveridad 2 | Un proceso productivo importante está detenido o degradado, pero la plataforma sigue disponible y hay operación parcial. | 2 horas hábilesmáximo | 8 horas hábilesobjetivo de workaround | Lun a Vie · 9:00 a 17:00hora del centro de México |
| MediaSeveridad 3 | Errores funcionales que afectan parcialmente un proceso, una ejecución, un dashboard, una integración o una funcionalidad, con alternativa operativa disponible y sin interrupción crítica. | 4 horas hábilesmáximo | 2 días hábilesobjetivo de atención o corrección, según diagnóstico | Horario hábillunes a viernes |
| Baja o solicitudSeveridad 4 | Consultas, configuraciones, dudas, mejoras menores, solicitudes administrativas o incidentes sin afectación operativa.Las nuevas funcionalidades y los cambios de alcance no forman parte del SLA de incidentes: se cotizan o se programan por separado cuando corresponde. | 1 día hábilmáximo | Se programasegún prioridad y alcance | Horario hábillunes a viernes |
- CríticaSeveridad 1
Plataforma productiva no disponible, varios procesos críticos detenidos, imposibilidad general de ejecutar automatizaciones, o indisponibilidad de Vision que afecte una operación crítica.
- Primera respuesta
- 1 hora
- Cobertura
- 24/7
- Objetivo de restauración
- 4 horas · objetivo de workaround o restauración, cuando está bajo control de Pynbot
El diagnóstico inicia de inmediato después de la primera respuesta.
- AltaSeveridad 2
Un proceso productivo importante está detenido o degradado, pero la plataforma sigue disponible y hay operación parcial.
- Primera respuesta
- 2 horas hábiles
- Cobertura
- Lun a Vie · 9:00 a 17:00
- Objetivo de restauración
- 8 horas hábiles · objetivo de workaround
- MediaSeveridad 3
Errores funcionales que afectan parcialmente un proceso, una ejecución, un dashboard, una integración o una funcionalidad, con alternativa operativa disponible y sin interrupción crítica.
- Primera respuesta
- 4 horas hábiles
- Cobertura
- Horario hábil
- Objetivo de restauración
- 2 días hábiles · objetivo de atención o corrección, según diagnóstico
- Baja o solicitudSeveridad 4
Consultas, configuraciones, dudas, mejoras menores, solicitudes administrativas o incidentes sin afectación operativa.
- Primera respuesta
- 1 día hábil
- Cobertura
- Horario hábil
- Objetivo de restauración
- Se programa · según prioridad y alcance
Las nuevas funcionalidades y los cambios de alcance no forman parte del SLA de incidentes: se cotizan o se programan por separado cuando corresponde.
Cuándo empieza a contar
El SLA comienza a contabilizarse cuando el incidente se reporta por un canal oficial y con la información necesaria para iniciar el diagnóstico.
Respuesta comprometida, restauración objetivo
El tiempo de primera respuesta es un compromiso. El de restauración es un objetivo: puede depender de la infraestructura del cliente, de APIs y sistemas de terceros, de proveedores cloud, de credenciales, de la red o de cambios realizados fuera de Pynbot.
Alcance del 24/7
La cobertura continua aplica exclusivamente a Severidad 1 en ambientes productivos identificados previamente. El resto de severidades se atiende en horario hábil.
Una sola plataforma
Los mismos tiempos aplican a Pynbot Automation y a Pynbot Vision. No hay una mesa de soporte para automatizaciones y otra para analítica.
Preguntas de TI
Lo que se pregunta en una revisión técnica.
Las que salen en toda revisión técnica, respondidas por lo que la plataforma hace hoy.
No por definición. Un robot necesita exactamente los mismos accesos que necesitaría la persona que hoy hace ese proceso. Si hoy se hace con un usuario estándar, el robot opera con un usuario estándar.
Pásanos tu checklist de seguridad.
Lo respondemos punto por punto, y te decimos con claridad qué sí y qué todavía no.