SOC agéntico vía marketplace: guía de compra y contrato

Un proveedor más en el registro. Un contrato con sus propios términos, una factura en dólares fuera de la factura de nube y un calendario de renovación que finanzas nunca cruza con el presupuesto de nube. La ruta directa para contratar detección y respuesta gestionadas funciona, y cobra en burocracia lo que debería cobrar en decisión.

La propuesta aprobada, sin embargo, puede entrar por la cuenta de nube. Un SOC agéntico (Security Operations Center, el centro de operaciones de seguridad, operado por agentes de IA con validación humana) cambia de mostrador, no de función. La pregunta deja de ser cuánto cuesta y pasa a ser quién responde.

El texto está escrito desde el lado del comprador. Los hallazgos que Security Hub ya agrega en la cuenta siguen saliendo por una autorización cross-account que el comprador concede y necesita revisar en cada renovación. La factura consolida. La responsabilidad, no.

Qué resuelve comprar un SOC agéntico en el marketplace

Comprar un SOC agéntico en AWS Marketplace usa el acuerdo de nube vigente: la compra entra como una línea en la factura consolidada, con precio y plazo en private offer. El anuncio de Aurora Agentic SOC, publicado en el blog de AWS Marketplace el 16 de octubre de 2026, atribuye a esa ruta menos sobrecarga de contratación, procurement más simple y facturación consolidada.

La suscripción no define quién responde por la operación, y ahí la factura deja de resolver.

Son atribuciones del anuncio, no mediciones.

Para quien ya contrata seguridad como servicio, la novedad no está en el servicio. Está en dónde se compra.

La tabla usa cinco criterios y aplica la lógica de compra directa o marketplace de software a un servicio continuo.

El anuncio cita el ISC2 2025 AI Pulse Survey, que estima que 30% de los equipos de seguridad ya integraron herramientas de IA a las operaciones.

La factura consolida, el acceso no

El pipeline que alimenta al SOC corre en la cuenta AWS del comprador. Security Hub CSPM agrega los hallazgos en ASFF, EventBridge dispara el evento, Firehose lo lleva al S3, Lambda lo enriquece, y el SOC lee el bucket por autorización IAM cross-account. La factura consolidada no reduce ese acceso.

GuardDuty, Inspector, Macie, Config y herramientas de terceros entregan hallazgos a Security Hub CSPM, que los normaliza en ASFF (AWS Security Finding Format). EventBridge dispara en cada hallazgo, sin polling.

Firehose lleva el evento al S3 con buffer y batching. Lambda procesa, enriquece y enruta hacia un bucket de destino, y el SOC lee ese bucket por IAM cross-account.

Las plantillas CloudFormation del proveedor implementan ese pipeline en la cuenta del comprador. El sistema que produce los datos vive del lado de quien compra.

Los agentes del framework Swarm of Experts hacen triaje, investigación y respuesta en el SOC, con analistas humanos validando y escalando. La integración descrita lee el bucket de destino, y lo que esa lectura alcanza está en el rol IAM y en el contrato, no en el anuncio.

El proveedor declara monitorear más de 10.000 clientes, procesar más de 10 billones de eventos de seguridad por semana y acumular más de 14 años de datos curados.

El AWS Shared Responsibility Model organiza el resto: AWS responde por la seguridad de la infraestructura, y el comprador sigue responsable de lo que corre en su cuenta, incluidos los recursos que crea el stack del proveedor. La confianza cross-account se concede, se revisa y se revoca en la cuenta del comprador. El proveedor asume el rol y opera el SOC del suyo.

Al comprador le queda la parte operativa que no aparece en la propuesta: cuotas de Firehose, ciclo de vida del bucket, costo del consumo y lectura de hallazgos por un tercero. Es contrato, no arquitectura.

Cuánto cuesta: suscripción y consumo son dos facturas

La contratación crea dos líneas de costo. La suscripción tiene precio y plazo negociados con el proveedor y aparece en la factura AWS consolidada. El pipeline consume servicios AWS pagos por uso, cobrados directo al comprador. Aprobar solo la primera línea deja la segunda sin dueño.

La segunda línea no negocia con nadie. Cada hallazgo se convierte en evento en Firehose, objeto en S3 e invocación de Lambda. El comprador paga a AWS por los recursos que crea el stack y por procesar los hallazgos, separadamente de la suscripción.

La facturación consolidada en AWS junta las dos en la misma factura. Solo una fue negociada, y la diferencia atraviesa el trimestre sin explicación.

Quien usa la mecánica de comprar software en el marketplace de la nube contra un compromiso de gasto necesita verificar en el acuerdo si la suscripción cuenta para el compromiso y cómo el consumo de servicios AWS entra en el trimestre.

El tratamiento tributario de la remesa no es el objeto de este texto.

La pregunta de presupuesto no es el precio de la suscripción. Es quién firma la línea variable cuando el volumen de hallazgos se duplica en una semana de incidente.

Plazo, renovación y la diferencia entre apagar y cancelar

El plazo, la renovación y la cancelación siguen los términos del acuerdo negociado con el proveedor, y el anuncio lo dice explícitamente. La remoción técnica es otra cosa: borrar los stacks CloudFormation interrumpe el envío de hallazgos y no cancela la suscripción.

Existen dos calendarios, y casi nunca coinciden. El del contrato tiene inicio, plazo, ventana de cancelación y fecha de renovación. El de la cuenta tiene stacks instalados y destinos apuntando a un bucket.

Borrar los stacks interrumpe el envío de hallazgos, y la suscripción sigue activa. La factura llega igual, porque la suscripción vive en el acuerdo, no en el stack. Quien cierra la operación sin cerrar el contrato paga por un servicio que ya no recibe datos.

Lo contrario también ocurre, y cuesta más: el contrato termina, el pipeline queda instalado, capturando hallazgos, gastando Firehose y llenando el S3 con un destino que nadie lee. Ninguno de los dos lados desinstala por cortesía.

La renovación sigue el acuerdo, y lo que dice tiene que leerse en la cláusula, no deducirse de la factura.

Dos preguntas resuelven esto antes de la suscripción. Quién percibe la renovación, y quién desinstala.

Aprobación y presupuesto: quién firma, quién es dueño de la línea, quién percibe la renovación

Consolidar el cobro cambia el camino de la aprobación. La compra pasa a competir con el presupuesto de nube, y el dueño de la línea ya no es necesariamente quien opera el servicio. Tres campos deben estar definidos antes de la suscripción: dueño, línea de presupuesto y alerta de renovación.

Cuando la suscripción entra en la factura de nube, deja de ser compra de seguridad y pasa a ser línea de nube. Quien aprueba presupuesto de nube rara vez aprueba herramientas de seguridad, y el monto compite con instancias y compromisos de gasto.

La private offer define precio, plazo y términos. Quien negocia suele ser procurement. Quien opera es el equipo de seguridad. Quien paga la línea variable suele ser nadie, hasta el primer incidente.

Separar las tres funciones es una decisión de diseño. Dueño del servicio, dueño de la línea y dueño de la alerta pueden ser la misma persona, siempre que esté escrito.

La línea necesita circular. Integrar procurement en el flujo con las APIs del marketplace lleva el cobro al procurement y al ERP, donde la renovación deja de depender de la memoria.

Qué verificar antes de firmar

Nueve verificaciones necesitan respuesta antes de la suscripción. Las tres primeras tratan de lo que los agentes pueden hacer, de la credencial usada y del alcance de la lectura cross-account. Las demás cubren retención, costo del lado AWS, unidad de precio, renovación, datos y la división entre lo que AWS cubre y lo que le queda al comprador.

1. Alcance de los agentes y el punto de validación humana. Los agentes hacen triaje, investigación y respuesta, y analistas humanos validan y escalan.
2. Qué credencial usa el proveedor. La lectura es por IAM cross-account, concedida en la cuenta del comprador, y la revocación necesita dueño y plazo.
3. Qué alcanza la lectura cross-account. Qué bucket, qué prefijo, y si el alcance crece.

Las tres primeras definen lo que el proveedor ve, y legal las lee con el equipo de seguridad.

1. Retención y ciclo de vida del bucket. Quién define la expiración, quién paga el almacenamiento y a dónde va el historial.
2. Requisitos previos y costo del lado AWS. Security Hub y GuardDuty necesitan estar habilitados, además de la suscripción activa, y generan consumo.
3. Unidad de medida del precio en la private offer. Por usuario, por volumen o por activo, y qué hace subir el número.

El bloque del medio queda fuera de la propuesta comercial, y ahí aparece el costo después.

1. Renovación, cancelación y lo que sobrevive al final. La renovación sigue el acuerdo, y sobrevive lo que no fue desinstalado.
2. Tratamiento de datos, subprocesadores y residencia. El pipeline corre en la cuenta del comprador y el SOC lee el bucket de destino, así que el dato atraviesa la frontera entre las dos cuentas en cada hallazgo procesado.
3. Qué cubre AWS y qué le queda al comprador. La operación de seguridad es lo que el comprador firma de vuelta.

Ninguna de las nueve es nueva para quien ya contrató seguridad. Todas cambian con la compra en el marketplace.

Cuándo el marketplace es la ruta equivocada

La ruta por el marketplace es la equivocada cuando el equipo no logra operar el pipeline en su cuenta, cuando la lectura por tercero no pasa por la política de datos, o cuando la compra necesita salir en moneda local con documento fiscal local. En esos casos, la consolidación no compensa.

La primera es operativa. Sin dueño para cuotas, ciclo de vida del bucket y revisión del IAM, la empresa hereda el trabajo.

La segunda es de datos. Una política que no admite lectura continua por tercero no cambia porque la factura quedó más simple.

La tercera es de contratación. Cuando la compra necesita salir en reales, con documento fiscal local y punto de contratación definido, la ruta cambia. Nexforce Marketplace contrata soluciones internacionales de software e IA con precio en reales, factura brasileña y procurement centralizado, con alertas de presupuesto y de renovación.

La consolidación de facturación resuelve la factura, no la responsabilidad. Nexforce Marketplace cambia la moneda, el documento fiscal y el punto de contratación, no quién responde por la operación de seguridad.

https://nexforce.ai/marketplace

La ruta por el marketplace de la nube compensa cuando el equipo opera el pipeline en su cuenta y la lectura por tercero pasa por la política de datos.

Preguntas frecuentes

¿Qué cambia al comprar un SOC agéntico en el marketplace?

La suscripción usa la cuenta AWS que la empresa ya tiene, con precio y plazo en private offer y cobro en la factura consolidada. Lo que no cambia es la operación. El pipeline sigue corriendo en la cuenta del comprador, con la misma responsabilidad sobre la operación.

¿Qué pasa con el pipeline si el contrato termina?

El SOC gestionado sigue instalado. Los stacks CloudFormation permanecen en la cuenta, capturando hallazgos y consumiendo Firehose, S3 y Lambda. Borrar esos stacks interrumpe el envío de hallazgos y no cancela la suscripción. Quién desinstala, y en qué plazo, queda definido en el contrato, incluso en el último día de vigencia.

¿Quién paga el consumo de AWS que genera el pipeline?

El comprador. La suscripción cubre el servicio del proveedor, y el pipeline consume servicios AWS pagos por uso, cobrados directo en la cuenta. Security Hub y GuardDuty necesitan estar habilitados, y Firehose, S3 y Lambda crecen con el volumen de hallazgos procesados en semanas de incidente.

¿Qué revisar en el acceso cross-account antes de firmar?

Qué bucket lee el proveedor, con qué prefijo, por qué cuenta y por qué credencial. Revisar también cómo se revoca esa autorización y si el alcance puede crecer sin nueva aprobación. Cuando el contrato termina, alguien debe definir quién se lleva el historial y quién borra lo que quedó.

¿Cuándo compensa contratar SOC en el marketplace?

Compensa cuando el equipo logra operar el pipeline en su cuenta y la lectura por tercero pasa por la política de datos. Cuando la compra necesita salir en moneda local, con documento fiscal local, el marketplace de la nube deja de ser la ruta más simple.

Referencias

Anuncio "Resolve security signals faster with Arctic Wolf's Aurora Agentic SOC", blog de AWS Marketplace, 16 de octubre de 2026. https://aws.amazon.com/blogs/awsmarketplace/resolve-security-signals-faster-with-arctic-wolfs-aurora-agentic-soc/ Consultado el 23 de octubre de 2026.

ISC2 2025 AI Pulse Survey, citado en el anuncio anterior. Consultado el 23 de octubre de 2026.

AWS, Shared Responsibility Model. https://aws.amazon.com/compliance/shared-responsibility-model/ Consultado el 23 de octubre de 2026.

El paso que sigue

La próxima tarea cabe en una hoja: llevar las nueve verificaciones a la mesa donde legal lee con el equipo de seguridad, escribir los tres nombres (dueño del servicio, dueño de la línea de presupuesto y dueño de la alerta de renovación) y pedir la private offer con la unidad de precio y la forma de revocación del acceso cross-account dentro del texto. Lo que quede fuera de esas tres líneas aparece en el trimestre siguiente, en la primera semana de incidente en que el volumen de hallazgos se duplique.

Después de eso la decisión es simple. Cuando la compra necesita salir en reales, con documento fiscal brasileño y punto de contratación definido, Nexforce Marketplace contrata soluciones internacionales de software e IA con precio en reales, factura brasileña y procurement centralizado, con alertas de presupuesto y de renovación. Cambia la moneda, el documento fiscal y el punto de contratación. No cambia quién responde por la operación de seguridad, y esa parte sigue en la cuenta del comprador, con el pipeline y el acceso cross-account bajo el IAM que la empresa concede y revisa.