Confianza + Arquitectura
Construido para compradores industriales que no pueden permitirse sorpresas.
La IA industrial se juzga por el peor día, no por el mejor. La arquitectura de KPT está diseñada alrededor de la pregunta que cada plant manager realmente hace: "¿cuál es el peor escenario si esto se comporta mal?"
Esta página se lee de arriba hacia abajo, pero está estructurada para tres audiencias: stakeholders corporativos, ingenieros de planta + proceso, y equipos de TI + seguridad. Salte a su sección si dispone de poco tiempo.
Para stakeholders corporativos
Seis promesas que KPT le hace a cada comprador.
Los no-negociables. Viven en nuestros contratos como garantías, no como claims de marketing.
IA glass-box, no reglas black-box
Cada variable que KPT promueve viene con una explicación legible por humanos: qué features impulsaron el lift, qué dice el contrafactual, qué probaría el siguiente experimento. Podemos mostrarle al operador por qué el modelo está recomendando un cambio antes de que él lo apruebe.
Puerta de confianza shadow-run de 30 días
Cada variable que KPT activa ha sido A/B-testeada contra sus datos reales por mínimo 30 días, con significancia estadística antes de la promoción. Los compradores industriales temen '¿y si lo empeora?' — construimos la respuesta dentro del producto.
Cloud + On-Prem, un solo codebase
KPT corre como SaaS multi-tenant en lighthouse.kpt.tech Y como contenedor on-prem en su datacenter. Mismo motor de optimización, misma UX, misma cadencia de releases. El aprendizaje cross-deployment ocurre vía patrones federados, nunca con datos crudos.
Escrituras planner-in-the-loop
KPT nunca escribe a su ERP / MES sin aprobación humana explícita. Las recomendaciones fluyen a través de una UI de revisión; los planificadores auditan, sobrescriben o aprueban. El sistema de registro sigue siendo el sistema de registro.
Aislamiento de datos por tenant
Los tenants cloud viven detrás de políticas de row-level security y autenticación gestionada. Los tenants on-prem reciben una llave de cifrado controlada por el tenant — KPT no puede descifrar el fine-tune del modelo local incluso con una vulneración total de la infraestructura.
Sin personalización de ERP, MES, WMS o TMS requerida
KPT se monta encima de sus sistemas core existentes — ERP (SAP, Oracle, Dynamics), MES, WMS, TMS — vía APIs estándar. Nunca modificamos la configuración de su sistema de registro. Su stack core se mantiene limpio, audit-friendly y migration-safe.
Actualización: conoce cómo KPT se integra con SAP S/4HANA — hoy, en 90 días y certificado.
Para ingenieros de planta + proceso
Lo que realmente significa en el piso de planta.
Las cuatro decisiones de diseño que determinan qué pasa en su turno cuando KPT recomienda un cambio — o cuando el propio KPT tiene un mal día.
Puerta de promoción
30 días, significancia estadística, luego live
Cada nueva variable entra en un shadow run: KPT computa la recomendación pero no la aplica. Trackeamos la recomendación contra lo que realmente pasó en su línea por 30 días. Solo las variables que vencen al baseline con significancia estadística graduan a LIVE — y usted ve toda la historia A/B antes de que el botón de promoción se habilite.
Ruta de escritura
Los planificadores aprueban. Siempre.
Incluso una variable LIVE no auto-escribe. KPT genera un cambio recomendado; su planificador lo ve en la cola de revisión con la explicación y el impacto proyectado; aprueba, sobrescribe o rechaza. La escritura solo ocurre después de esa aprobación — y la decisión queda registrada con el nombre del planificador.
Modo de falla
Si KPT se comporta mal, nada se rompe
KPT es una capa que propone cambios. Su ERP / MES / WMS / TMS existente continúa corriendo exactamente como lo hacía antes de que KPT fuera instalado. Si nos caemos, su planta corre con los mismos workflows que tenía ayer — simplemente dejamos de mandar recomendaciones hasta volver. No hay ruta crítica a través de KPT.
Tres formas de despliegue
Cloud SaaS, cloud aislado, o contenedor on-prem
PoC y equipos small-mid corren en nuestro cloud compartido con almacenamiento de base de datos tenant-isolated. Los clientes enterprise reciben lanes de cómputo aislados (boundary de red separado, opcionalmente base de datos separada) sobre la misma plataforma gestionada. Sitios altamente regulados o air-gapped corren un contenedor firmado en su propio datacenter — los datos crudos nunca abandonan su red.
Para equipos de TI + seguridad
Protección de datos, por arquitectura.
Cuatro garantías sobre aislamiento de datos + aprendizaje federado, más seis capas de postura de seguridad estándar. Revisable por su equipo de compliance; ejecutable por auditoría.
Los datos crudos nunca abandonan sus instalaciones (modo on-prem)
Cuando KPT está desplegado on-prem, el agente no tiene endpoint outbound capaz de exportar lecturas de sensores, eventos de MES, parámetros de receta o cualquier telemetría operacional. El tráfico outbound está restringido a una allowlist hardcoded: updates de software firmados desde el release registry de KPT, warm-starts de modelos federados en boot del agente, y (solo opt-in) updates encriptados agregados a la federación. La allowlist es ejecutable por auditoría y está publicada en nuestra documentación contractual.
Ninguna parte individual — incluyendo KPT — ve nunca los gradientes individuales de un cliente
Cuando opta al aprendizaje federado de patrones, su agente envía updates de gradiente DP-noised al coordinador de KPT. El coordinador corre agregación segura: un protocolo criptográfico que suma updates de todos los clientes opted-in sin descifrar ninguna contribución individual. Los ingenieros de KPT ven solo el modelo federado agregado — nunca sus updates individuales. Esto está matemáticamente garantizado por el protocolo, no solo es un compromiso de política.
Las estadísticas agregadas llevan ruido de privacidad diferencial
Los agregados cross-customer que KPT publica (por ejemplo, "a través de nuestros clientes de confitería, las variables de tiempo de mezcla promediaron +0.5% de mejora de yield") se generan solo cuando al menos cinco tenants han contribuido Y solo después de que se agrega un término de ruido calibrado. El ruido está dimensionado a un presupuesto formal de privacidad diferencial trackeado por publicación. Incluso un adversario con conocimiento auxiliar de todos menos un tenant no puede reverse-engineerear la contribución del tenant retenido a partir de cualquier número de agregados que publiquemos.
Cada patrón cross-tenant que llega a la pantalla de otro cliente fue revisado por un ingeniero de KPT nombrado
Cuando la variable de un cliente gradúa a LIVE y supera un umbral de impacto, el sistema la propone como arquetipo generalizable para el KPT Commons (la biblioteca de patrones compartida). Antes de que ese arquetipo se publique, un ingeniero de procesos de KPT lo revisa: abstrae la variable para que sea despojada de cualquier detalle identificador del tenant, generaliza sus precondiciones, y decide si se merge en un arquetipo existente, se vuelve uno nuevo, o se rechaza como tenant-específico. El log de revisión lista el nombre del ingeniero, la fecha y la decisión de abstracción.
Postura de seguridad estándar
Seis capas que su equipo de seguridad reconocerá.
Identidad y acceso
Proveedor de identidad gestionado, tokens de sesión basados en JWT, refresh-rotation en cada request autenticado, MFA-ready. El role-switching de personal interno a un tenant de cliente está gateado y logueado con la identidad del miembro del staff, el tenant de origen, el tenant de destino y el timestamp.
Aislamiento de datos
Políticas de row-level security en la base de datos gestionada ejecutan el filtrado por tenant en la capa de almacenamiento. Una cláusula WHERE olvidada en código de aplicación no puede filtrar datos entre tenants — la base de datos lo rechaza. Las lecturas cross-tenant son matemáticamente imposibles sin un policy override explícito (el cual a su vez es auditado).
Edge de red
TLS 1.2+ en todas partes, HSTS, emisión de certificados CAA-pinned restringida a una sola CA confiable, protección DDoS automática en el edge del CDN. Sin API keys de larga vida en contexto del navegador; todas las llamadas privilegiadas fluyen a través de la capa de identidad gestionada.
Secretos y cifrado
Los secretos de aplicación viven en un vault gestionado y rotan en un calendario fijo; sin llaves de larga vida en código fuente, en archivos env o en CI. Datos en reposo usan AES-256 en la capa de almacenamiento. Los despliegues on-prem reciben una llave controlada por el tenant para que KPT no pueda descifrar el fine-tune del modelo local incluso con una vulneración total de la infraestructura.
Audit log
Append-only por tenant. Cada acción que cambia estado — promoción de variable, democión, cambio de suscripción, switch de tenant de staff KPT, aprobación de sugerencia, password reset — escribe una fila inmutable con el actor, el sujeto y los metadatos. El log sobrevive reinicios de contenedor, rebuilds de infraestructura y migraciones. Los clientes enterprise pueden exportar su audit trail completo en cualquier momento.
Política de migración never-erase
Cada migración de base de datos es aditiva por default. Las operaciones destructivas requieren un header BACKWARD_INCOMPATIBLE explícito en el docstring de la migración con una justificación escrita. CI bloquea cualquier migración sin él de llegar a producción. Combinado con snapshots automáticos pre-migración, los datos del cliente no pueden perderse por acción de ingeniería.
Para ingenieros
Arquitectura, en patrones.
Suficiente detalle para que su equipo de ingeniería evalúe KPT competentemente — no lo suficiente para que un competidor clone el pegamento de integración. Los nombres específicos de proveedores, IDs de servicio y detalles de config viven en docs gateados por NDA que compartimos durante la revisión de seguridad.
Ingesta
Los conectores extraen de su ERP / MES / WMS / TMS en un calendario que usted controla. La validación + normalización + tenant-tagging ocurren en el boundary; el input crudo nunca se confía as-is río abajo.
Aislamiento de tenant
Cada request lleva un tenant claim, seteado como variable de sesión de base de datos en la entrada. Las políticas de RLS en cada tabla customer-scoped ejecutan el filtrado. La ruta de código de la aplicación no ejecuta el tenant scoping — la base de datos sí.
Motor de optimización
Solver de restricciones multivariado (CP-SAT + branch-and-bound custom para los edges pesados) sobre toda su superficie de variables, más una capa ML de descubrimiento de patrones que propone nuevas variables, más una etapa LLM-assisted de sugerencia de variables para input en lenguaje natural del operador. Stateless — cada corrida es reproducible desde los inputs.
Puerta de promoción
El harness shadow-run registra la recomendación del modelo junto con el outcome real por mínimo 30 días. Las variables solo graduan cuando el lift es estadísticamente significativo. La puerta es parte del motor, no un check río abajo.
UI del planificador
Presentación glass-box de recomendaciones: qué variables impulsaron el cambio, qué dice el contrafactual, qué probaría el siguiente experimento. El planificador aprueba, sobrescribe o rechaza. La decisión queda registrada con la identidad del planificador antes de cualquier write-back.
Write-back
APIs estándar hacia su ERP / MES / WMS / TMS — sin personalización de su lado, sin cambios de schema. Las escrituras están gateadas tras la aprobación del planificador y auditadas. Si su sistema de registro rechaza la escritura, la recomendación queda parqueada, no perdida.
Tracking de impacto
Capa de atribución de KPI mide el delta real entre ventanas KPT-on y KPT-off para cada variable promovida. Alimenta el leaderboard que los clientes ven; alimenta los contratos que firmamos (nos pagan por impacto medido, no por vibes).
Lo que NO está en el stack
Cinco cosas que deliberadamente no hacemos — usualmente la segunda pregunta que hacen los revisores de seguridad.
- × Analytics o session-replay trackers de terceros en dashboards de clientes.
- × Llamadas outbound a KPT durante modo on-prem que no estén en la allowlist publicada.
- × Datos crudos del cliente fluyendo a proveedores LLM — solo metadata abstracta de variables fluye.
- × Un pipeline de "mejora de modelo" que scrape datos del cliente sin opt-in explícito.
- × Personal de KPT con acceso permanente a datos del cliente. El acceso es role-switched + logueado por sesión.
IDs específicos de proveedor + servicio, version pinning y suites de pruebas de integración se comparten bajo NDA mutuo estándar durante la revisión de seguridad. Contacte security@kpt.tech para solicitar el paquete.
Cómo engagear
Para revisión más profunda.
Soportamos la mayoría de los procesos formales de revisión que los equipos enterprise de TI y compliance usan, sobre base de NDA mutuo estándar.
Cuestionarios de seguridad. Respondemos los comunes (CAIQ, SIG, formularios internos custom) dentro de 5 días hábiles para oportunidades activas.
Revisión SOC2-readiness. Compartimos nuestro mapeo de controles actual, análisis de gaps y timeline de remediación. La atestación SOC2 Type 2 está en el roadmap 2026.
Auditoría de penetración de terceros. Los clientes enterprise pueden correr un pen test one-time en el ambiente de staging o contratar a su auditor preferido para un alcance anual. Proporcionamos la superficie de test + SLA de remediación.
Términos contractuales custom. Opt-out de aprendizaje federado, compromisos de residencia de datos, ventanas de notificación de brechas y derechos de auditoría son negociables en el MSA enterprise.
La confianza no es un feature
Es toda la arquitectura.
La puerta de confianza shadow-run de 30 días, la IA glass-box, la ruta de escritura planner-in-the-loop, el aislamiento de datos por tenant — estos no son bullets de ventas. Son la respuesta a la única pregunta que importa en IA industrial: ¿qué pasa cuando se comporta mal?