AgriNet · seguridad y auditoría
Un control que no deja registro no existe. Aquí está el registro de cada control.
Cuando el auditor llega sin avisar, no pregunta si tiene seguridad. Pregunta quién capturó ese dato, a qué hora y con qué permiso. Esta página enumera los controles del sistema, la evidencia que cada uno deja y la norma que lo pide.
Auditable quiere decir una sola cosa: que se puede reconstruir
Un sistema es auditable cuando un tercero que no estuvo ahí puede reconstruir qué pasó, quién lo hizo y cuándo, sin depender de que alguien se acuerde. Todo lo demás —contraseñas, cifrado, perfiles— existe para que esa reconstrucción sea creíble. Si el expediente se puede alterar sin dejar rastro, el cifrado no lo salva.
En la agroindustria de exportación esa reconstrucción tiene tres jueces distintos y ninguno acepta la palabra del otro. La autoridad sanitaria del país destino pide el registro por evento. El organismo certificador pide la evidencia de que el procedimiento se siguió. Y su comprador, que responde por usted ante su propia autoridad, pide poder verificarlo él mismo. Los tres preguntan por el mismo dato y ninguno de los tres avisa.
Por eso esta página no describe una política de seguridad. Describe controles, y junto a cada control, el registro que deja. Lo que viene de la plataforma sobre la que AgriNet corre lleva su cita en el expediente interno. Lo que es obligación de su empresa se dice con esas palabras: es del operador.
El control que no produce un renglón fechado no es un control: es una intención.
El primer control
Quién entra: autenticación y sesión
El acceso al sistema pasa por un servidor de autenticación propio que emite un token de sesión firmado. El portal de la plataforma y las aplicaciones de campo no hablan con la base de datos: hablan con una capa de servicios que exige ese token en cada llamada. El token es de vida corta y se renueva; una sesión abandonada en una tableta dentro del empaque deja de servir por sí sola.
Esto importa en su operación por una razón concreta: las aplicaciones por rol de campo, cosecha, inocuidad, recepción, almacén y transporte capturan fuera de línea y sincronizan al recuperar conectividad. Un registro que se captura en una parcela sin señal y se sincroniza dos horas después debe llegar con la identidad de quien lo capturó y con la hora en que lo capturó, no con la hora en que el servidor lo recibió.
El control de acceso, componente por componente
| Control | Qué hace | Dónde está la evidencia |
|---|---|---|
| Autenticación OAuth 2.0 | Emite el token de sesión contra el directorio de usuarios; el resto de los servicios no autentica por su cuenta | portal y ejecución.NET Framework 4.8 con Web API 5.2.3 |
| Token JWT firmado, de vida corta | Cada llamada al API viaja con el token; el token caduca y se renueva sin volver a pedir la contraseña | Vida del token y renovación desde la capa intermedia |
| Una sola puerta de entrada al dato | 499 controladores de API sobre una misma capa base: no hay acceso directo a la base desde la pantalla | 500 archivos de controlador, clase base |
| Captura fuera de línea con identidad | Las aplicaciones de campo capturan sin señal y sincronizan después, conservando responsable y hora del evento | Apps por rol del sistema — brochure, sección 09 |
Fuente: evidencia de plataforma de la casa y brochure de AgriNet · verificado al 27 de septiembre de 2026
La casa mantiene sus propios hallazgos de seguridad documentados con severidad y con el procedimiento para reproducirlos, dentro del repositorio técnico de la plataforma, y los trata como deuda con dueño y fecha (citado). Se dice aquí porque un proveedor que afirma no tener hallazgos no está diciendo que su producto sea seguro: está diciendo que no los busca.
Quién puede qué: perfiles y permisos por rol
El permiso no se resuelve escondiendo botones. Se resuelve en la capa de datos: el menú, las pantallas y las operaciones que un usuario ve se arman preguntando por su rol antes de dibujar nada. La plataforma tiene un procedimiento dedicado a eso, spGetMenuConfigurationbyRole, y el permiso vive en una tabla propia que cruza pantalla, funcionalidad y rol (permiso_pantalla_funcionalidad; el procedimiento).
Los permisos no se capturan a mano pantalla por pantalla. La tarea 120 del motor de la plataforma asigna permisos por rol y siembra los catálogos, y el sistema incluye un tipo de pantalla de configuración con árbol de permisos para revisarlos y moverlos después.
En AgriNet los roles son los de la operación, no los de un organigrama de informática: jefe de campo, responsable de cosecha, responsable de inocuidad, jefe de empaque, jefe de CEDIS, coordinador de exportación, dirección de operaciones, y dos portales externos —proveedor y cliente— que ven sólo lo suyo. El comprador que audita entra a verificar lo que su propio programa de verificación de proveedores extranjeros le obliga a poder verificar, y no ve nada más.
- Segregación de funciones donde importa. Quien captura el resultado de una evaluación de agua no es quien libera el producto; quien arma el expediente documental de exportación no es quien autoriza la salida de la unidad.
- El portal externo es un rol, no una excepción. El proveedor sube su documentación al mismo expediente donde será auditada, con su propio usuario.
- El rol se ve en pantalla. El sistema abre con la vista puesta por el rol; no hay una pantalla genérica desde la que todos vean todo.
Un permiso que sólo existe en el manual se rompe el primer día que alguien se va de vacaciones.
Quién hizo qué y cuándo: la bitácora
El motor de estados de la plataforma no deja cambiar un estado sin registrarlo. Cada transición pasa por una validación que comprueba el estado de origen, el estado de destino y el rol del usuario, y al ejecutarse escribe dos rastros: el historial de la entidad —con estado anterior y estado nuevo— y una bitácora transversal con la operación marcada como cambio de estado, el valor anterior y el valor nuevo.
Las citas exactas son para la validación, para la validación de rol, para la ejecución, para el historial de la entidad y para la bitácora con operación, valor anterior y valor nuevo.
Dos condiciones más viajan con la transición y no son decorativas: requiere comentario y requiere evidencia. Son columnas de la propia matriz de transiciones. Traducido a su operación: hay pasos que el sistema no permite cerrar sin que alguien escriba por qué, y pasos que no cierran sin el archivo adjunto.
La pregunta del auditor no es «¿tienen bitácora?». Es «enséñeme quién cambió este dato y por qué». Eso es una consulta, no una búsqueda.
La plataforma genera además pantallas de auditoría como tipo propio —con indicadores arriba, línea de tiempo y rejilla de detalle, detecta campos de auditoría al generar cada pantalla y publica en la documentación viva del proyecto dos piezas que un auditor pide por su nombre: el modelo de seguridad con su matriz de permisos y la matriz de trazabilidad y auditoría.
Los controles, uno por uno, con su evidencia y su norma
Control · qué deja de registro · qué norma lo pide
| Control | Qué registro deja | Norma o exigencia que lo pide | Origen |
|---|---|---|---|
| Identidad en cada captura | Usuario, fecha y hora en el evento; responsable por etapa del cultivo | 21 CFR Part 1 Subpart S: los datos clave se asocian al evento crítico | Norma · brochure sección 02 |
| Permiso por rol y por funcionalidad | Tabla de permiso pantalla-funcionalidad-rol y menú resuelto por rol | Control de acceso como control del sistema de gestión de inocuidad | Plataforma |
| Bitácora de cambio de estado | Estado anterior, estado nuevo, valor anterior, valor nuevo, usuario, hora | Integridad del registro ante auditoría no anunciada | Plataforma |
| Comentario obligatorio en transiciones sensibles | Texto del responsable, adherido a la transición | Justificación documentada de la decisión | Plataforma |
| Evidencia obligatoria en transiciones sensibles | Archivo adjunto —fotografía, análisis, certificado— ligado a la transición | 21 CFR Part 112: evidencia fotográfica fechada y georreferenciada de terrenos adyacentes | Plataforma · norma · brochure sección 09 |
| Validación documental antes de la salida | Registro de completitud del expediente del embarque antes de que la unidad salga del CEDIS | Documentación de exportación y coherencia documental ante aduana | Brochure sección 03 y 08 |
| Versionado de artefactos y de cambios | Instantánea de versión por cambio aplicado, con número de versión | Control de configuración y de versiones | Plataforma |
| Vigencia de certificados como dato, no como archivo | Esquema, alcance, organismo certificador, número de certificado y caducidad, con su estatus | Esquemas reconocidos GFSI y verificación del comprador bajo FSVP | Brochure sección 07 |
| Retención del registro | El registro permanece consultable después de cerrado el lote | 21 CFR Part 1 Subpart S: dos años de conservación | Norma · brochure sección 04 |
Fuente: 21 CFR Part 1 Subpart S y Subpart L, 21 CFR Part 112, brochure de AgriNet y evidencia de plataforma · verificado al 27 de septiembre de 2026
Nueve controles, nueve registros, nueve citas. Eso es lo que se puede enseñar en una sala de auditoría.
Retención: dos años, y el día que se los pidan
La regla de trazabilidad alimentaria de la FDA fija dos obligaciones que suelen confundirse. Una es de conservación: los registros de trazabilidad se guardan durante dos años. La otra es de entrega: cuando la autoridad los solicite, se entregan en un plazo de 24 horas, en formato electrónico y ordenable. La segunda es la que quiebra a los archivos en carpetas: conservar dos años de papel es posible; entregar en 24 horas dos años de papel ordenado por lote, no.
Retener es una decisión de configuración, no de buena voluntad. En el sistema, el registro de un lote cerrado sigue siendo consultable, y el expediente se arma en consulta, no en transcripción. El simulacro de retiro cronometrado que trae la suite existe precisamente para medir eso contra el reloj de las 24 horas antes de que llegue la solicitud real.
Hay dos cosas que el sistema no puede hacer por usted y se dicen aquí. La primera: decidir el periodo de retención cuando su contrato con el comprador pide más de dos años. Ese umbral lo fija su empresa. La segunda: el respaldo y la recuperación de la infraestructura donde el sistema corre, que se opera con su área de sistemas o con su proveedor de alojamiento.
Respaldo, ambientes y control de versiones
Separar el ambiente donde se prueba del ambiente donde se opera no es una cortesía: es lo que evita que una corrección de un martes borre el expediente de un lote embarcado el lunes. La plataforma separa la base de cada proyecto —una base por sistema generado— y trata la creación del sitio, la base y los servicios como pasos con su propio registro.
Todo cambio aplicado sobre un sistema en operación pasa por una secuencia que incluye una comprobación previa, un respaldo del artefacto que se va a tocar, el cambio, el posproceso y una instantánea de versión con su número. Esa instantánea es lo que permite responder a la pregunta incómoda: «¿cómo estaba esta pantalla el 14 de marzo, cuando se capturó ese dato?».
Dicho con precisión, para que nadie lea de más: ese respaldo es el del cambio, no el respaldo corporativo de su base de datos. La política de respaldo, la prueba de restauración y el plan de recuperación ante desastres son del operador. El sistema le entrega los documentos que esos planes necesitan como expediente —continuidad del negocio, recuperación ante desastres, ambientes, control de versiones, plan de despliegue—, pero no ejecuta su política por usted.
Quién responde por qué
| Asunto | De la plataforma | Del operador |
|---|---|---|
| Autenticación y emisión de sesión | Servidor de autenticación y token firmado | Alta y baja de usuarios, y quién queda con qué rol |
| Permisos | Modelo de permiso por rol, pantalla y funcionalidad | La decisión de negocio: quién aprueba qué |
| Bitácora | El registro automático de cada transición | Revisarla. Una bitácora que nadie lee es un archivo, no un control |
| Retención | El registro sigue consultable y el expediente se arma en consulta | El periodo, cuando su contrato pide más que la norma |
| Respaldo y recuperación | Respaldo del artefacto en cada cambio aplicado, con versión | Política de respaldo, prueba de restauración y plan de recuperación |
| Ambientes | Base y servicios separados por sistema; despliegue registrado | Quién tiene acceso a cada ambiente y con qué credencial |
| Cumplimiento ante la autoridad | La evidencia, ordenada y entregable | Cumplir. La responsabilidad no es delegable a un software |
Reparto de responsabilidad declarado · 27 de septiembre de 2026
El expediente de auditoría que el sistema deja
La plataforma sobre la que corre AgriNet no sólo genera la aplicación: genera el expediente técnico del sistema. El catálogo tiene 211 documentos en 18 secciones, sin huecos ni duplicados en el rango, definidos en código (el conteo y las secciones). Dos de esas secciones son exactamente lo que un auditor de sistemas pide antes de mirar la pantalla.
La sección de seguridad de la información reúne quince documentos, entre ellos la matriz de controles de seguridad, la política de control de acceso, la de clasificación de la información, la de cifrado y protección de datos, el plan de respuesta a incidentes, el plan de continuidad del negocio y el de recuperación ante desastres. La sección de gestión de la configuración reúne diez, entre ellos el registro de elementos de configuración, el plan de control de versiones, el documento de ambientes y el informe de auditoría de configuración.
Las dos secciones del expediente que sostienen una auditoría de sistemas
| Sección | Documentos | Piezas que un auditor pide por su nombre |
|---|---|---|
| Seguridad de la información | 15 | Plan de seguridad, declaración de aplicabilidad, evaluación y tratamiento de riesgos, política de control de acceso, clasificación de la información, continuidad del negocio, recuperación ante desastres, cifrado y protección de datos, privacidad, respuesta a incidentes, evaluación de vulnerabilidades, seguridad en el desarrollo, matriz de controles, concienciación |
| Gestión de la configuración | 10 | Plan de gestión de configuración, registro de elementos de configuración, informe de estado, plan de líneas base, informe de auditoría de configuración, matriz de dependencias, plan de control de versiones, registro de liberaciones, documento de ambientes, plan de despliegue |
| Gestión de cambios | 10 | Plan de gestión de cambios, registro de solicitudes de cambio, informe de impacto, informe de cambios implementados, documento de reversión |
| Compliance y regulaciones | 12 | Incluye el informe de auditoría interna de cumplimiento |
Fuente: catálogo de documentos técnicos de la plataforma, verificado en código, secciones 06, 07, 09 y 11 · 27 de septiembre de 2026
Ese expediente es la diferencia entre decir «el sistema es seguro» y poner sobre la mesa la matriz de controles, el registro de versiones y el informe de auditoría de configuración del sistema que usted usa. El auditor no discute adjetivos: pide documentos.
Cuando el expediente del sistema existe, la auditoría deja de ser un proyecto y pasa a ser una consulta.
Lo que esta página no afirma
Tres cosas se dejan dichas para que nadie las lea de más, porque en esta capa la credibilidad se gasta una sola vez.
AgriNet le permite demostrar cumplimiento. La responsabilidad de cumplir sigue siendo suya, y así lo dicen las propias normas.
- No existe una certificación de la FDA para software. La autoridad registra instalaciones e inspecciona; no certifica programas. Un sistema puede declararse preparado para la regla 204 y sostener con qué; no puede declararse certificado por la FDA.
- No se publica ninguna cifra de tiempo del sistema que no esté medida. Las cifras de latencia que circulan en el material técnico interno son estimaciones sin instrumentación, y por eso no aparecen en esta página ni en ninguna otra.
- La conformidad con un esquema de certificación es de su unidad de producción, no del software. El sistema sostiene la evidencia que el auditor pide; la certificación la emite el organismo certificador a su nombre.
Preguntas frecuentes
¿Cómo entra un usuario y qué pasa si pierde la tableta en el campo?
El acceso pasa por autenticación OAuth 2.0 contra el servidor de la plataforma, que emite un token de sesión firmado y de vida corta; cada llamada al API viaja con ese token y el token caduca por sí solo. Si un equipo se pierde, la baja del usuario corta el acceso desde el servidor, no desde el equipo. El alta y la baja de usuarios son del operador.
¿Queda registro de quién modificó un dato del expediente del lote?
Sí, y con valor anterior y valor nuevo. El motor de estados de la plataforma escribe el historial de la entidad con estado anterior y estado nuevo y una bitácora transversal con la operación marcada como cambio de estado, el valor anterior, el valor nuevo, el usuario y la hora. Hay transiciones que además exigen comentario del responsable o archivo de evidencia para poder cerrarse.
¿Cuánto tiempo hay que conservar los registros de trazabilidad?
Dos años, según 21 CFR Part 1 Subpart S. La obligación de entrega es distinta y más exigente: cuando la autoridad los solicita, se entregan en 24 horas en formato electrónico y ordenable (§ 1.1455). Si su contrato con el comprador pide un periodo mayor, el umbral se parametriza; la decisión es de su empresa.
¿El sistema hace el respaldo de mi base de datos?
No como política corporativa. Cada cambio aplicado sobre el sistema en operación incluye un respaldo del artefacto que se toca y una instantánea de versión con su número, lo que permite reconstruir cómo estaba una pantalla en una fecha dada. La política de respaldo de la base, la prueba de restauración y el plan de recuperación ante desastres son del operador. El sistema entrega los documentos que esos planes necesitan como parte del expediente técnico.
¿Qué pasa cuando llega una auditoría no anunciada?
GLOBALG.A.P. IFA v6 habilita un 10 % de auditorías no anunciadas, y el brochure lo nombra como el escenario donde el papel falla. Lo que se enseña es el expediente vivo: el certificado con su esquema, alcance, organismo, número y caducidad; la evaluación de agua del año; el registro por evento del lote; y la bitácora de quién capturó qué. Nada de eso se arma en el momento: ya está.
¿Puede mi comprador en Estados Unidos verificar lo mío sin que yo le mande archivos?
Para eso existe el portal de cliente como rol con su propio usuario y su propia vista. Su importador está obligado bajo el programa de verificación de proveedores extranjeros (21 CFR Part 1 Subpart L) a verificar que usted produce con controles equivalentes; el portal le deja verificar exactamente eso y nada más. Su comprador en Estados Unidos no puede importar lo que no puede verificar.
Referencias
- FDA · Requirements for Additional Traceability Records for Certain Foods (Food Traceability Rule), 21 CFR Part 1 Subpart S. Registros por evento crítico, conservación de dos años y entrega en 24 horas (§ 1.1455). Consultada el 27 de septiembre de 2026. ↗
- FDA · Foreign Supplier Verification Programs (FSVP), 21 CFR Part 1 Subpart L. Obligación del importador de verificar al proveedor extranjero. Publicada el 27 de noviembre de 2015. Consultada el 27 de septiembre de 2026. ↗
- FDA · Standards for the Growing, Harvesting, Packing, and Holding of Produce for Human Consumption (Produce Safety Rule), 21 CFR Part 112. Evidencia de inspección de terrenos adyacentes. Consultada el 27 de septiembre de 2026. ↗
- GLOBALG.A.P. · Integrated Farm Assurance v6, ediciones Smart y GFS. Desde el 1 de enero de 2025 toda auditoría de frutas y hortalizas se hace contra v6. Consultada el 27 de septiembre de 2026. ↗
- GS1 · EPCIS Standard, Release 2.0 (ratificada en junio de 2022). Modelo de evento de visibilidad con JSON-LD y API REST, vehículo técnico de los datos clave por evento crítico. Consultada el 27 de septiembre de 2026. ↗
- SENASICA · Procedimiento de certificación en Sistemas de Reducción de Riesgos de Contaminación (SRRC), modalidades BPA, BPM, BPCo y BUMP. Consultado el 27 de septiembre de 2026. ↗
- Evidencia de plataforma: dossier técnico del motor de la casa, archivos, con cita de archivo y línea en el expediente interno sobre código en disco. Verificado el 27 de septiembre de 2026.
El modelo
Primero ve su sistema funcionando, sin costo y sin compromiso. Después decide si lo compra o lo renta.
No es un demo: es AgriNet con sus procesos, sus áreas y su operación dentro. Entra, lo recorre y lo usa. Verlo no cuesta nada y no lo compromete a nada. Cuando decida, cobramos por resultados, no por entregables.