Los volúmenes de phishing siguen subiendo. Eso era predecible. Lo nuevo es la calidad. Microsoft reporta crecimiento sustancial en correos generados con LLMs. La gramática perfecta, el tono profesional, la personalización por información pública del target — todo lo que antes era pista para detectar phishing, hoy es nivel base.

El problema con eso: los entrenamientos de awareness de hace tres años están obsoletos. “Busca errores ortográficos” ya no es señal. El correo phishing de hoy no tiene errores. “Busca tono extraño” ya no es señal. El correo phishing está bien escrito.

Lo que sí sigue funcionando como señal

Análisis de origen. Headers, dominios sutilmente alterados, infraestructura de envío. Defender for Office hace este trabajo bien. La pieza humana se reduce a “verifica antes de actuar en cosas inusuales”.

Análisis de contexto. ¿El CEO realmente te pide a ti, en este formato, en este momento, por este canal? Si rompe patrón, sospecha. La regla “si rompe patrón, valida por canal alterno” sigue válida.

Análisis de intent. Defender XDR ahora marca correos por intent — financial fraud attempt, credential theft, etc. La clasificación por intent es más útil que por superficie.

Lo que cambió en mi operación

Bajé las expectativas de que el usuario detecte el phishing. La línea de defensa principal ya no es “el usuario que duda”. Es la pila de detección automatizada: anti-spoofing, sandboxing, intent analysis, link rewriting con análisis dinámico. Si llega al inbox un phishing decente, asumo que un porcentaje de usuarios va a caer.

Subí la inversión en respuesta rápida post-click. Cuando un usuario hace click en un link malicioso, ¿qué pasa? La velocidad entre click y contención es lo que marca la diferencia. Defender XDR más Security Copilot reduce esto.

Capacitación distinta. Ya no enseño a “detectar phishing por errores”. Enseño a “validar por canal alterno cualquier solicitud financiera o de credenciales no esperada”. Es regla simple. La gente la sigue.

Para dónde va esto

La carrera entre phishing generado por IA y detección por IA va a definir el panorama de email security los próximos años. Es asimétrica — el atacante necesita pasar uno, el defensor necesita parar todos. Pero las herramientas defensivas están mejorando rápido también.

Mi predicción: en 2027 el email puro como vector va a perder relevancia frente a vectores multi-canal (email más SMS más voz, con IA orquestando los tres). La defensa va a tener que cubrir el customer journey completo, no solo el inbox.

Leer el artículo en Cloud Legion

El 1 de mayo arranca la disponibilidad general de Agent 365. Quince dólares por usuario al mes. He visto comentarios mixtos en LinkedIn — unos dicen que es un robo, otros que es regalado. Como casi siempre, depende.

Voy a tratar de ser concreto sobre qué te dan por ese precio. Lo escribo aprovechando que estuve dos semanas haciendo el piloto en uno de los tenants donde tengo manos.

Lo primero: Agent 365 no es un producto, es un control plane. Esa distinción importa. No te da más capacidad de Copilot. Te da más visibilidad y control sobre los agentes que ya existen y los que vienen. Si tu organización no tiene aún muchos agentes desplegados, el ROI es difícil de defender el primer trimestre. Si tienes Copilot Studio en uso o gente experimentando con agentes locales, la cosa cambia.

Lo que viene en la caja a mayo 2026

Runtime Protection (preview). Esto es lo que más me interesa. Monitorea al agente en tiempo de ejecución. Si el agente hace algo raro — accede a un origen no esperado, llama un API que no debería, mueve un archivo a un lugar improbable — lo flaggea. Y, si tú lo configuras así, le revoca permisos automáticamente. Es la primera vez que veo a Microsoft tratar a un agente como tratan a un endpoint con Defender. Misma filosofía: comportamiento, no firma.

Network-Layer monitoring. Extiende los controles de Entra Internet Access a los agentes. Esto significa que las conexiones del agente pasan por la misma inspección que ya tienes para los usuarios. Lo más valioso es restringir destinos web aprobados. Si tu agente solo puede hablar con APIs de tu lista, los exfil exploits a la EchoLeak pierden el destino.

Shadow AI discovery. La pieza que más me sorprendió en el piloto. Defender + Intune detectan agentes locales corriendo en endpoints Windows. Empezó con OpenClaw. La hoja de ruta menciona explícitamente GitHub Copilot CLI y Claude Code. Es decir, Microsoft está poniendo en su radar a los agentes que corren fuera de su stack. Pragmático. Honesto. Necesario.

Centralización en una consola. Registro de agentes, permisos, propietarios, telemetría, alertas. Antes esto vivía repartido entre Entra, Defender, Purview y la consola de Copilot Studio. Ahora hay un sitio único. Que funciona razonablemente bien — algunos paneles aún cargan lentos, pero mejor que pelearse con cuatro pestañas.

¿15 dólares por usuario al mes vale la pena?

Mi cálculo. Si tienes más de 500 usuarios con Copilot Studio activo y agentes en producción, el incidente que evitas con Runtime Protection paga el año completo. Si tienes menos de 100 y solo agentes “experimentales”, probablemente puedas esperar al refresh de cuatro o seis meses. El upside del precio es que escala sin que pagues por agente — pagas por usuario humano. Para una empresa donde un humano tendrá pronto seis o siete agentes ejecutándose en su nombre, es un modelo razonable.

Lo que me incomoda del precio: te obliga a pagar por usuarios que ni tocan agentes. No hay tier para “solo licenciar a quienes los usan activamente”. Microsoft sabe que la curva de adopción va hacia arriba, así que apuesta por cobrar todo el rebaño. Aceptable, pero opaco.

¿Qué hago si fuera tú? Lo que hice yo: piloto de 90 días con un grupo controlado, métricas claras antes de empezar (cuántos agentes registrados, cuántas anomalías detectadas, cuántos shadow agents encontrados), y decisión basada en datos. Si el shadow AI discovery te encuentra en el primer mes diez agentes que no sabías que existían, el precio se justifica solo. Si te encuentra cero, igual te dice algo importante: o estás muy maduro o no estás mirando bien.

Ya veremos cómo evoluciona. Por ahora, prefiero tenerlo activo a no tenerlo.

Leer el artículo en Cloud Legion

Voy a explicar qué cambia.

El risk scoring funciona como en humanos. Defender mira señales: ubicación geográfica anormal, accesos fuera de horario, acciones desviadas del patrón histórico, conexiones a destinos sospechosos. Combina señales en un score. Te alerta cuando un agente se comporta raro.

Diferencias con humanos

Los patrones son distintos. Un humano tiene ritmos circadianos. Un agente puede estar activo 24/7. La ausencia de ritmo circadiano no es señal sospechosa para un agente. Defender lo aprende.

La velocidad es distinta. Un agente puede legítimamente hacer 1000 acciones por minuto. La señal “muchas acciones rápidas” no aplica igual. Lo que sí aplica: cambio brusco respecto a la baseline del propio agente.

El contexto es distinto. Un humano tiene “manager”, “departamento”, “rol”. Un agente tiene “sponsor”, “scope autorizado”, “tipo de tarea”. El risk scoring de Defender ahora incorpora estos atributos en su modelo.

Lo que se ve en mi tenant

Detectó tres anomalías en el primer mes. Una era benigna — un agente cambió de comportamiento porque cambió su tarea, no estaba mal. Dos eran problemáticas — un agente que empezó a tocar datos fuera de su scope (mala configuración después de un update), y otro que empezó a fallar en patrones que sugerían que su modelo subyacente había sido cambiado sin aviso.

Ese segundo caso me marcó. Era un agente custom de Copilot Studio. Alguien del equipo de IA cambió el modelo subyacente sin avisar a seguridad. Defender lo detectó por el cambio en el patrón de respuestas. Me dio visibilidad sobre algo que estaba mal gobernado. Pude presentarle al equipo de IA evidencia técnica de por qué el cambio sin aviso no es OK.

Lo que ajusté en operación

Subí los thresholds para alertas críticas. Por defecto, Defender es ruidoso para agentes nuevos hasta que aprende la baseline. Las primeras dos semanas tuve más alertas que las que mi equipo podía triagear. Microsoft documenta esto, hay que esperar.

Conecté las alertas con tickets automáticos al sponsor del agente. Si un agente de María entra en risk alto, María recibe ticket. La accountability es del sponsor.

Empecé a usar el risk score en políticas de Conditional Access. “Si un agente está en risk alto, requiere re-autenticación de su sponsor humano antes de continuar acciones críticas”. Esto añade fricción a un agente comprometido, sin parar a los buenos.

Lo que me gustaría que mejoraran

Más explicabilidad en las alertas. A veces Defender dice “risk alto” sin explicar qué señales pesaron. Para investigación, necesito saber el por qué.

Integración con Entra Agent ID más profunda. Hoy hay puente, pero algunos atributos del agente no se reflejan en el modelo de risk. Espero que cierren ese gap.

Mi conclusión: risk scoring para identidades de agentes era el control que faltaba. Lo tienes activo, vas mucho más tranquilo. Si tienes agentes en producción y no estás monitoreando con risk scoring, es la pieza que más rápido te baja el riesgo de identidad de agente.

Leer el artículo en Cloud Legion

Antes, cuando un analista del SOC tenía un incidente abierto, vivía con dos pestañas: la del incidente y la de Security Copilot. Copiaba contexto entre ambas. Pegaba IDs, hashes, IPs, nombres de host. La fricción era constante. Yo medí un día cuántos clicks gastaba un analista L2 en una hora de triage cruzando Defender con Copilot. 437 clicks. Cuatrocientos treinta y siete.

Ahora el chat vive dentro del incidente. Le preguntas al modelo sobre el incidente abierto, sin copiar nada. El contexto ya está cargado.

Las preguntas que más se hacen mis analistas

“Qué dispositivos están afectados”. Te lo da con confidencias por dispositivo.

“Cuáles son las identidades comprometidas”. Lista, con riesgo asignado.

“Compárame este incidente con los tres últimos parecidos”. Aquí brilla. Antes esto era un script de búsqueda ad-hoc en KQL. Ahora una pregunta.

“Qué acciones recomendarías en orden”. Te las prioriza con justificación. No siempre acierta. Pero la lista te ahorra el primer borrador.

Lo que está mejor de lo que esperaba

La calidad de las respuestas con contextos largos. Defender tiene incidentes con cientos de eventos. La ventana de chat los resume bien. No vi alucinaciones graves en mis tres semanas. Vi imprecisiones — un par de veces dijo “endpoint X” cuando era “endpoint Y” — pero detecto bien con un segundo de revisión.

Lo que está peor de lo que esperaba

La latencia. Para incidentes grandes, la primera respuesta tarda 8 a 12 segundos. Después es más rápido. Los analistas se quejan del primer paso. Microsoft sabe, está prometido bajar.

Lo que cambió en mi operación

Bajé el tier 1 a la mitad. No despedí a nadie — los moví a tier 2. El modelo hace el triage inicial de muchos incidentes. Los analistas humanos validan y deciden las acciones complejas. Mi MTTD bajó algo. Mi MTTR bajó más.

Subí los criterios de las cosas que Security Copilot puede ejecutar autónomamente. Antes era todo “sugerir, humano ejecuta”. Ahora hay un puñado de acciones (aislar dispositivo confirmado, bloquear IP en blocklist conocida, deshabilitar cuenta en lista de acciones aprobadas) que el modelo ejecuta solo, con notificación. La auditoría duerme tranquila porque cada acción tiene log y razón.

Subió mi consumo de SCUs. Esto es importante. La ventana de chat es seductora. Los analistas la usan más. Y cada query gasta. Si no metes cost caps por usuario, el final del mes te va a sorprender. Yo los puse en la segunda semana después de que un analista corrió 600 queries en un turno. Útil. Caro.

¿Lo recomendaría? Sí. Es de las cosas que justifican Security Copilot por sí solas, si tu SOC tiene volumen. Si tu SOC trabaja 5 incidents por día, no se nota. Si trabaja 50, cambia tu vida.

Una cosa que pediría a Microsoft: poner el chat también en Sentinel con el mismo nivel de integración. Hoy la experiencia entre ambos es desigual. Mismo motor, distinta integración. Espero que en próximos updates lo cierren.

Al final, esto es lo que compras con Security Copilot incluido en E5: que esté ahí donde el analista ya está mirando. La integración es la mitad del valor del modelo.

Leer el artículo en Cloud Legion

Voy a contar cómo lo manejo, porque sé que hay otros CISOs leyendo esto que están en la misma encrucijada.

Lo primero: el comité de auditoría no quiere oír “Copilot está bien gestionado porque tenemos sensitivity labels”. El comité quiere oír qué riesgo específico estás controlando, cómo lo mides, cómo lo monitoreas, quién es accountable, qué evidencia tienes.

Mi entry en el risk register de Copilot tiene seis ítems separados. Lo aprendí a fuerza de iteraciones.

Riesgo 1 — Filtración de datos por respuestas inapropiadas

Causa: oversharing de permisos más grounding amplio. Control primario: SAM más Purview DLP más sensitivity labels. KRI: porcentaje de prompts bloqueados por DLP por mes, tendencia. Evidencia: dashboard de Purview con histórico.

Riesgo 2 — Prompt injection y exfiltración asistida

Causa: contenido externo procesado por el modelo. Control: Prompt Shields más Spotlighting más URL allowlist más confirmación de acciones con efecto lateral. KRI: número de incidents de Prompt Shield triage por mes, severidades. Evidencia: tickets de SOC.

Riesgo 3 — Identidades de agente sin governance

Causa: agentes desplegados sin sponsor o sin scope claro. Control: Entra Agent ID más sponsor tasks más access reviews. KRI: porcentaje de agentes registrados sobre total detectado, agentes huérfanos. Evidencia: reporte trimestral de Entra Agent ID más Agent 365.

Riesgo 4 — Shadow AI en endpoints

Causa: agentes locales no inventariados. Control: Defender más Intune discovery más política de allowlist. KRI: número de agentes detectados fuera de lista, evolución mensual. Evidencia: dashboard de Defender.

Riesgo 5 — Dependencia de proveedor y continuidad

Causa: dependencia crítica de Microsoft 365 más servicios de IA. Control: planes de continuidad, BCP/DR del proveedor revisado, alternativas evaluadas. KRI: SLA cumplido, incidents reportados por Microsoft. Evidencia: reportes contractuales.

Riesgo 6 — Cumplimiento regulatorio

Causa: requisitos cambiantes (EU AI Act, regulaciones locales). Control: legal más compliance reviews trimestrales, in-country processing donde aplique. KRI: gaps identificados en último review. Evidencia: actas de los reviews.

Cada riesgo tiene dueño nombrado. Cada control tiene evidencia. Cada KRI tiene umbrales.

Lo que aprendí presentando esto

El comité no premia complejidad. Premia claridad. Mi primera presentación tenía 20 ítems. Bajó a 6. Cada uno entendible en 30 segundos. Si tu entry no se lee en 30 segundos, no se lee.

El comité quiere ver evolución. Una foto del riesgo hoy es menos útil que la tendencia. ¿Estamos mejor o peor que hace 6 meses? ¿Por qué? Esa narrativa es lo que te da credibilidad o te la quita.

El comité quiere oír qué pasaría si fallara el control. No solo “tenemos control X”. También “si X falla, qué tenemos”. Defensa en profundidad explicada con palabras, no jerga.

Lo que más me costó

Convencer a operación de que cada control necesita evidencia documentada. “Lo hacemos pero no lo escribimos en ningún lado”. Ese es el peor estado posible. La evidencia que no existe, en una auditoría, es un control que no existe. Tomó meses cambiar el hábito.

Convencer a finanzas de que el budget de seguridad de Copilot no es opcional ni puntual. Es operativo, recurrente. Si quieres mantener los controles, financia la operación, no solo el setup.

Convencer al equipo de IA de que governance no es enemigo de innovación. Es lo que le permite a innovación durar. Esto fue cultural y tomó un año entero.

Mi consejo

No copies mi lista. Tu contexto es distinto. Pero usa la estructura: causa, control, KRI, evidencia, dueño. Eso es transversal.

Empieza pequeño y honesto. Mejor 3 riesgos bien gestionados que 15 mal documentados. El comité huele el bullshit a kilómetros.

Habla con tu auditor antes de la primera presentación. Pregúntale qué quiere ver. Te ahorras un trimestre de reescritura.

Y la última: este risk register no es estático. Cada quarter cambia. Hace seis meses no tenía la categoría de shadow AI. Hace tres no tenía in-country processing. La velocidad del espacio te obliga a actualizar. Si tu entry de Copilot se ve igual hace un año, probablemente no estás mirando.

Leer el artículo en Cloud Legion

El Top 10 no es un descubrimiento — la mayoría de las categorías ya las veníamos manejando. Lo valioso es que da nomenclatura común. Cuando hablo con un auditor, con un cliente, con un nuevo miembro del equipo, podemos decir “AAI:01 - Memory Poisoning” y los dos sabemos a qué nos referimos. Antes era cada uno con su jerga.

Voy a recorrer rápido cómo lo aterrizo en Copilot Studio. No es una guía exhaustiva, es lo que hago yo.

Recorrido por los 10

AAI:01 Memory Poisoning — el agente acumula contexto, alguien lo contamina, el agente actúa sobre datos envenenados. En Copilot Studio: limito el scope de la memoria del agente, no le doy acceso a memorias persistentes salvo necesidad clara, audito qué entra a la memoria del agente. Si el agente consume documentos compartidos, los pasamos por sensitivity labels y DLP antes de que entren a su corpus.

AAI:02 Tool Misuse — el agente usa una herramienta para algo distinto a su propósito. En Copilot Studio: cada conector con scope mínimo necesario. Si el agente solo necesita leer del CRM, no le des escritura. Si solo en una tabla, no en todas. Esto requiere paciencia con el setup pero paga después.

AAI:03 Privilege Compromise — el agente termina con más permisos de los que debería. En Copilot Studio: revisión periódica de permisos del agente. Entra Agent ID más access reviews. Esto es lo que hablé en otro post — meter al agente al ciclo de governance estándar.

AAI:04 Resource Overload — el agente consume tantos recursos que se vuelve indisponible o caro. En Copilot Studio: rate limits, cost caps por agente, monitoring de consumo. Si un agente sube su consumo súbitamente, alerta.

AAI:05 Cascading Hallucinations — un agente alucina, otro toma esa salida como verdad, y la cadena de errores crece. En Copilot Studio multi-agente: validación entre nodos, no encadenar agentes sin un punto de verificación. Costoso pero necesario en flujos críticos.

AAI:06 Intent Breaking and Goal Manipulation — esto es prompt injection con vocabulario más fancy. En Copilot Studio: Prompt Shields activo, Spotlighting cuando hay inputs de fuera, system prompts robustos, validation de outputs.

AAI:07 Misaligned and Deceptive Behaviors — el agente hace algo que parece OK pero no es lo que el usuario quería. En Copilot Studio: confirmación explícita de acciones con efecto lateral. Si el agente va a mandar correo, modificar archivo, ejecutar transacción — confirma con el humano. Esto, aunque agrega fricción, es no-negociable.

AAI:08 Repudiation — el usuario o el agente niega haber hecho una acción y no hay forma de probarlo. En Copilot Studio: logging completo activado en Purview, identidad de agente clara (Entra Agent ID), trazabilidad end-to-end. Auditable es no-negociable.

AAI:09 Identity Spoofing and Impersonation — alguien se hace pasar por el agente o el agente se hace pasar por alguien. En Copilot Studio: identidad robusta del agente, autenticación mutua donde aplica, MFA en quien crea o modifica agentes.

AAI:10 Overwhelming HITL — el humano en el loop recibe tanto input que deja de validar. En Copilot Studio: diseño de aprobaciones que no satura. Si tu agente genera 1000 acciones al día y todas requieren aprobación humana, la aprobación deja de ser real. Hay que pensar el HITL como recurso escaso.

Cómo lo opero

He empezado a documentar cada agente en una matriz: para cada uno de los 10 ítems, ¿cuál es nuestro control, cuál es la evidencia, quién es el dueño? Cuando el auditor llega — y va a llegar — el documento ya existe. No lo armas la semana antes.

¿Es todo? No. Hay categorías que el Top 10 cubre superficialmente. Por ejemplo, supply chain de modelos: si tu agente usa un modelo custom, ¿cómo lo verificaste? Eso está implícito en varios ítems pero no es categoría propia. Lo cubro aparte.

¿Lo recomendaría como base para tu programa? Sí. Tener el Top 10 como vocabulario y línea base, y construir tu programa por encima, te ahorra inventar la rueda. Que es lo que más tiempo nos hace perder en seguridad: discutir taxonomía cuando deberíamos estar implementando controles.

Leer el artículo en Cloud Legion

Voy a contar para qué sirve esto en los términos en que se lo expliqué a mi gerente, que no es técnico pero firma los presupuestos.

Una cosa es proteger los archivos en reposo. Si tienes un PDF con contratos confidenciales, le pones un sensitivity label “Confidencial - Externo Restringido”, y Copilot ya no lo procesa para usuarios fuera del scope autorizado. Esa parte estaba.

Otra cosa, y aquí es donde estábamos cojos, es proteger lo que el usuario teclea en el prompt. Imagínate que el usuario está pidiendo a Copilot que le ayude a redactar un correo y, sin pensar, copia y pega un número de tarjeta de crédito de un cliente. O un número de seguridad social. O un fragmento entero de un contrato bajo NDA. Eso no es un archivo etiquetado. Es texto plano que el usuario metió a la fuerza. Antes de la nueva DLP, ese contenido se procesaba sin más.

Ahora, Purview escanea el prompt en tiempo real buscando Sensitive Information Types (SITs). Hay built-in para datos como SSN, tarjetas, IBANs. Y puedes definir custom — por ejemplo, “código de proyecto interno X-confidential” o el nombre clave de tu producto que no se debe filtrar. Si lo detecta, bloquea la respuesta. Copilot no responde. El usuario ve un mensaje de policy.

Qué tan bien funciona

Razonablemente. He hecho pruebas con tres SITs custom y dos built-in. Falsos positivos: pocos pero existen, sobre todo cuando los SITs custom tienen patrones genéricos. Falsos negativos: encontré un par cuando el usuario partía el dato sensible en dos prompts seguidos. La DLP no correlaciona conversación; mira prompt por prompt. Eso es un gap real.

La latencia agregada es mínima. En mis pruebas, menos de 200ms. No la sienten los usuarios.

Mi orden recomendado

Primero, defines el corpus de SITs que tienen sentido para tu negocio. No metas todo lo que se te ocurra — cada SIT activo es coste de inferencia y potencial fricción. Yo arranqué con seis: tarjetas, SSN/CURP local, IBAN, dos nombres de proyecto críticos, y un patrón regex para códigos internos. Suficiente para empezar.

Segundo, lo pones primero en modo audit, no block. Una semana en audit te dice si tu corpus es razonable. Si en una semana se dispararían 5,000 bloqueos al día, algo está mal.

Tercero, comunicas a los usuarios antes de cambiar a block. Un correo simple. “A partir del lunes, si pegas datos sensibles en Copilot, no responderá. Aquí los tipos de datos. Si tienes que trabajar con esto, usa este canal alternativo”. Sin esa comunicación, los tickets te entierran.

Cuarto, mides. ¿Cuántos prompts bloqueados por semana? ¿De qué usuarios y áreas? ¿Hay patrones que sugieran necesidad de capacitación? La DLP es solo el dique. La cultura es el río.

Lo que me sigue molestando es que la correlación cross-prompt no existe todavía. Si el usuario es astuto, puede partir un dato sensible y meterlo en pedazos. La DLP de prompts no lo va a pillar. Para eso, necesitas combinar con Insider Risk en Purview. Microsoft sabe que es un gap y dicen que están trabajando.

Para mí, esta es la pieza del 2026 que más rápido cambia el riesgo real de Copilot. Si solo puedes hacer una cosa este trimestre, hazla esta.

Leer el artículo en Cloud Legion

Pero es lo que toca.

Microsoft Entra Agent ID, todavía en preview a mayo de 2026, es la pieza estructural. La idea es simple: el agente no es un script anónimo que corre con el token de un humano. El agente tiene su propia identidad, sus propios permisos, su propio dueño accountable, y entra al ciclo de vida de IGA igual que un empleado.

Lo que cambia en la práctica

Antes, si el agente “robot-X” hacía algo raro, el log decía “user: maria.gonzalez”. Tenías que preguntarle a María si era ella o su agente. Ahora el log dice “agent: robot-x | sponsor: maria.gonzalez”. Forensia más limpia, accountability sin ambigüedad.

Antes, cuando María se iba de la empresa, el agente seguía corriendo con su identidad heredada hasta que alguien se acordara. Ahora hay sponsor tasks en Lifecycle Workflows: si el sponsor humano sale, hay un workflow que pide reasignar o suspender al agente. No es perfecto — la implementación a veces requiere intervención manual — pero existe el carril.

Antes, no podías hacer access reviews sobre lo que un agente puede ver. Ahora sí. Y aquí va lo importante: la primera vez que corrí un access review sobre un agente de Copilot Studio que llevaba ocho meses corriendo, encontré que tenía acceso a SharePoint sites que ya nadie usaba. Permisos que se habían heredado de la cuenta de servicio que el agente reemplazó. Limpiamos casi 200 permisos huérfanos en una tarde.

Lo que no me gusta

Que sigue siendo preview. Quiero esto en GA ya. Las features de governance de identidades de máquina nunca van rápido en el roadmap, y entiendo por qué (es complicado hacerlo bien), pero el problema ya está aquí.

Que la integración con Copilot Studio aún tiene gaps. No todos los agentes legacy se migran solos. Tienes que ir uno por uno reasignando, lo cual con una empresa con cientos de agentes pequeños es trabajo manual.

Que el billing de las identidades de agente no está claro todavía. Microsoft dice que se factura como parte de Agent 365, pero la documentación todavía es ambigua sobre cuándo cuenta como identidad facturable y cuándo no. He visto facturas con sorpresas.

Para empezar

Define la política primero, antes de tocar el portal. ¿Qué agentes requieren sponsor? ¿Cuántos sponsors mínimos necesita un agente crítico, uno o dos? ¿Cómo defines “crítico” para empezar? ¿Qué pasa si el sponsor está de vacaciones, sigue corriendo el agente o se pausa? Sin estas definiciones, te vas a meter en un lío político con managers que se sienten responsables de algo que no entienden.

Inventario antes que governance. Si no sabes cuántos agentes corren ya en tu tenant, el primer ejercicio es contarlos. Yo hice un script básico de exportar todo lo que Copilot Studio reporta y crucé contra lo que Defender ya estaba viendo. Aparecieron varios que no estaban en mi lista. Eso solo ya valió el ejercicio.

Y por último — y esto es opinión personal — no esperes a que GA salga para empezar a pensar en esto. La gobernanza de identidades de agente va a ser el control compensatorio más importante del 2026 y 2027. Si llegas tarde, no hay forma de retro-encajarlo limpiamente.

Leer el artículo en Cloud Legion

Qué hace el agente

Tres cosas principales. Analiza tus políticas de Conditional Access existentes para encontrar contradicciones, redundancias, gaps. Sugiere optimizaciones — consolidar, simplificar, fortalecer. Y, opcionalmente con tu aprobación, las aplica.

Mi tenant tenía 47 políticas de Conditional Access. Acumuladas a lo largo de tres años, con dueños distintos, criterios distintos, niveles de comprensión distintos. El estándar de muchos tenants medianos.

El agente, primer scan: marcó 4 contradicciones, 11 redundancias, 6 gaps. Total 21 hallazgos de los 47 policies.

Los hallazgos

Las contradicciones eran graves. Una política bloqueaba acceso desde geografía X. Otra, más reciente, lo permitía con condición Y. La interacción entre ambas dejaba un escenario donde acceso desde X con Y pasaba sin la fricción que la política original quería. Yo no había detectado esa interacción.

Las redundancias eran ruido. Tres políticas hacían lo mismo con criterios ligeramente distintos. Consolidamos en una con criterios bien definidos.

Los gaps eran lo más útil. Casos donde “esperarías” tener una política y no había. Por ejemplo: ningún policy bloqueaba tokens de OAuth obtenidos desde aplicaciones de tercer país no aprobado. Lo cubrimos.

Lo que el agente hace bien

Volumen de análisis. Yo no tengo el tiempo de revisar 47 policies con detalle cada quarter. El agente sí.

Patrones conocidos. Microsoft ha visto millones de configuraciones. El agente conoce los antipatterns. Los marca.

Sugerencias razonadas. No solo dice “cambia X por Y”. Dice “X tiene problema A, te sugiero Y porque resuelve A sin abrir gap B”.

Lo que el agente no hace bien

Lo específico de tu negocio. El agente no sabe que tu sucursal en X tiene una excepción legítima por razones que no están documentadas. Las sugerencias en esos casos pueden empujar hacia una simplicidad que rompe operación. Hay que filtrar.

Lo político. “Reducir esta política afecta al departamento de Y, que va a quejarse”. El agente no ve esa dinámica. Tú sí.

Cómo lo opero

Reviso al agente quincenalmente. No diariamente — me satura. No mensualmente — me pierdo cosas. Quincenal funciona.

Apruebo cambios solo si los entiendo. La tentación de “auto-aprobar todo lo que sugiera” es real. La resisto. Cada cambio que aprueba, lo entiendo. Si no lo entiendo, no lo apruebo. Eso me ha bajado la velocidad pero subido la confianza.

Roto el dueño de las revisiones. Antes era yo siempre. Ahora roto entre dos personas del equipo. Eso me da double-check humano sobre el agente.

Mi métrica: número de incidents de identidad relacionados con misconfiguration de CA. Bajó 40% el primer trimestre con el agente activo. Suficiente para justificar el costo de SCUs.

¿Recomendación? Si tu tenant tiene más de 20 policies de CA, el agente vale la pena. Si tienes menos, probablemente no necesitas la herramienta. La complejidad escala el valor.

Leer el artículo en Cloud Legion

Vi treinta y siete.

OpenClaw en máquinas de marketing. Claude Code en máquinas de desarrollo. GitHub Copilot CLI en varias laptops de ingeniería. Algún agente custom que ni siquiera pude identificar al primer intento — resultó ser un script con un MCP server montado por alguien del equipo de data science.

Esto es shadow AI. Y a febrero 2026, es probablemente el riesgo más subestimado de las organizaciones medianas y grandes.

Defino shadow AI como cualquier agente o herramienta de IA que opera en endpoints o en la nube de la empresa sin estar registrada, gobernada o auditada por el equipo de seguridad. La parte “sin gobierno” es la importante. No es que sea malicioso — la mayoría no lo es. Es que está fuera del radar.

Por qué importa

Primera razón: estos agentes operan con permisos del usuario que los corre. Si el usuario tiene acceso a tu CRM, el agente local también. Y el agente no sigue las mismas reglas que tú aplicas a Copilot empresarial. No tiene Prompt Shields, no tiene DLP de Purview, no tiene logging unificado. Lo que filtre, ya está filtrado.

Segunda: muchos de estos agentes mandan datos a APIs de terceros. Cada query hecha a un agente local que se conecta a la API de Anthropic, OpenAI, o cualquier otro proveedor, manda contexto fuera. Si ese contexto incluye texto sensible — y casi siempre incluye algo — tienes flujo de datos no inventariado.

Tercera: al ser locales, sobreviven a apagones de servicios cloud y a controles de red. Si tu firewall corporativo bloquea el dominio del proveedor, el agente local que ya tenía credenciales y caché puede operar offline parcialmente. Hay menos puntos de control que con servicios SaaS.

Lo que está dando Microsoft

Microsoft empezó a atacar esto en serio con Defender más Intune. La capacidad de descubrir agentes locales — empezó con OpenClaw y se expandió a GitHub Copilot CLI y Claude Code — es el primer paso. Te dice qué tienes. Después tú decides qué hacer.

Las opciones

Bloquear todo. Política dura: ningún agente local en endpoints corporativos. Ventaja: simple. Desventaja: matas productividad real, y la gente buscará caminos. Le pasó a una empresa amiga: bloquearon Claude Code, los devs lo siguieron usando desde laptops personales conectadas a recursos de la empresa por VPN. Empeoraron el problema.

Permitir todo. Política blanda: la gente usa lo que quiera. Ventaja: nadie protesta. Desventaja: no sabes qué pasa. No me parece responsable.

Permitir con governance. Lo que yo hago. Lista permitida de agentes locales aprobados (Claude Code y GitHub Copilot CLI están en mi lista hoy). Configuración obligatoria que registra el agente con identidad de Entra Agent ID. Logging activado. Restricciones por destinos web y por tipos de datos.

Esto último es lo que hace posible la combinación de Agent 365 más Defender más Intune. Hace doce meses, ni siquiera tenía la capacidad técnica de hacer governance sobre estos agentes. Ahora sí.

Lo que aprendí en el camino

No subestimes el número. Vas a encontrar más de lo que esperas. Si tu primer escaneo te encuentra dos, mira mejor — probablemente hay diez.

No subestimes el valor que la gente le saca. Hay quien usa Claude Code seriamente para trabajo crítico. Bloquearlo sin alternativa es romper el flujo de alguien que está aportando. Habla con los usuarios antes de cortarles.

Sí subestima la conciencia que tienen sobre los riesgos. Mucha gente buena, talentosa, técnica, no tiene la menor idea de que su prompt se manda a un servidor externo. Lo da por hecho. Las charlas de awareness siguen siendo importantes.

¿Hacia dónde va esto? A mi juicio, hacia un modelo de “AI runtime” empresarial donde los agentes locales son ciudadanos de primera clase pero con governance. Microsoft está apostando a que sea su control plane (Agent 365) el que orquesta. Otros proveedores tienen visiones distintas. La pelea por el control plane de los agentes va a ser una de las grandes en el 2027.

Por ahora, escanea. Inventariа. Decide. No mires hacia otro lado.

Leer el artículo en Cloud Legion

ISO 42001 es el primer estándar internacional de Sistema de Gestión de IA. Annex A tiene 38 controles agrupados. La estructura es similar a ISO 27001 pero el enfoque es distinto: gobernar el ciclo de vida de sistemas de IA.

El alcance importa más de lo que parece

Si declaras “todos los sistemas de IA de la empresa” en tu alcance, te metes en un berenjenal. Yo declaré “sistemas de IA con impacto en clientes externos y procesos críticos internos”. Eso me dejó fuera del scope pilotos experimentales y herramientas internas de bajo riesgo. La auditora aceptó.

Copilot 365 es complicado de encajar

Es un sistema de IA, está dentro del alcance de cualquier organización con uso empresarial. Pero el control no es solo tuyo. Es de Microsoft. ¿Cómo justificas controles sobre algo que no controlas tú?

Lo que hice. Documenté el contrato con Microsoft como evidencia primaria de controles compartidos. DPA, EDP, attestations. Cada control de Annex A donde Microsoft es responsable principal, lo apoyé con documentación contractual.

Para los controles donde la responsabilidad es mía (configuración, supervisión, uso adecuado), construí mi documentación. Políticas internas de uso, capacitaciones, monitoreo, incident response.

Para los controles donde es responsabilidad compartida, documenté el split: qué hace Microsoft, qué hago yo, dónde está la frontera. Esto fue lo más laborioso.

El AI System Impact Assessment de cada caso de uso significativo de Copilot. Cada agente custom tiene su AIAS. Plantilla común, contenido específico.

Lo que me sorprendió

Que la auditoría no exigió evidencia técnica profunda de Copilot — Microsoft ya tiene certificaciones que la auditora aceptó como base. Mi trabajo fue probar mi gobierno encima de eso, no replicar la auditoría de Microsoft.

Que la madurez del programa importa más que la cantidad de documentos. La auditora preguntó cómo decido aprobar un nuevo caso de uso de Copilot. Le mostré el comité, las plantillas, las decisiones recientes con sus rationales. Eso convenció más que mil páginas estáticas.

Lo que está mal en muchos programas que vi después

Sobredocumentación. Mil páginas de políticas que nadie ha leído. Nadie aprueba un programa con políticas estáticas que no se aplican.

Subimplementación. Mucha política, poca evidencia operativa. La política dice “revisamos riesgos trimestralmente” pero no hay actas trimestrales. La auditora lo huele.

Si te pones a esto: empieza por el alcance honesto, después los AIAs de tus casos de uso principales, después la política. La política sin casos no protege a nadie.

Leer el artículo en Cloud Legion

El error clásico, que cometí mis primeras dos veces: empezar por la tecnología. “Copilot es un sistema basado en LLMs que…”. Tres minutos después, el chair está mirando su teléfono. Cinco minutos después, el CFO pregunta qué tiene que ver esto con el budget.

El acercamiento que sí funciona: empezar por el riesgo de negocio.

Estructura que uso

Diapositiva 1. “Copilot está siendo usado por X% de nuestros empleados. En el último Q realizó N millones de operaciones”. Foto del estado, sin opinión. Datos.

Diapositiva 2. “El uso productivo está acelerando estos workflows: A, B, C. Estimamos un valor anualizado de Y”. Beneficio, en términos que el board entiende. Ahorro de tiempo, ingreso accelerado, costo evitado.

Diapositiva 3. “Los riesgos que estamos gestionando son tres: filtración de datos, decisiones automáticas mal supervisadas, dependencia operativa de proveedor”. Tres, no quince. Cada uno con un control primario y un KRI.

Diapositiva 4. “Estos controles tienen este performance en los últimos 6 meses”. Tendencia, con verde/amarillo/rojo. Sin números detallados.

Diapositiva 5. “Lo que vamos a hacer en los próximos 6 meses”. Tres iniciativas, con dueños y fechas.

Diapositiva 6. “Pregunta y respuesta”. Espacio para el board.

Total: 6 diapositivas. 12 minutos. Quedan 18 para Q&A.

Las preguntas reales del board

El board pregunta por dependencia. “¿Qué pasa si Microsoft tiene un outage de cuatro días?”. Es una pregunta legítima y hay que tener respuesta. La mía: BCP documentado, alternativas evaluadas, procesos críticos no enteramente dependientes de Copilot. El board duerme tranquilo si la respuesta es honesta.

El board pregunta por decisiones automáticas. “¿Tomamos decisiones que afectan a clientes con IA?”. La respuesta debe ser clara: dónde sí, dónde no, con qué supervisión. No alarmes, no minimices.

El board pregunta por reputación. “¿Qué pasa si Copilot dice algo público que nos dañe?”. Tiene que haber plan: detección, respuesta, comunicación. Un incidente reputacional sin plan es noticia.

Lo que evito decir

Jerga. “Prompt injection” no es palabra para el board. “Manipulación maliciosa de instrucciones a la IA” sí.

Falsa certeza. “Estamos completamente protegidos” miente. “Tenemos defensa en profundidad y los riesgos identificados están bajo control compensatorio” es honesto.

Detalles técnicos que no pidieron. Si me piden detalle técnico, lo doy. Pero no lo regalo sin pedir.

¿Funciona? La medida que uso: ¿el board hace mejores preguntas la siguiente vez? Si sí, está funcionando. Si la pregunta es la misma de hace seis meses, no entendieron. Hay que cambiar la presentación.

Mi métrica favorita: las preguntas del board sobre Copilot pasaron de “¿qué es esto?” hace 18 meses a “¿cómo evolucionamos nuestra postura ante el EU AI Act?” en la última. Esa es la curva de madurez del board, y es lo que más vale el ejercicio.

Leer el artículo en Cloud Legion

Entre las tendencias destacadas se encuentran:

• AI Supercomputing Platforms: arquitecturas híbridas que combinan CPU, GPU y chips neuromórficos para procesar cargas masivas de IA.
• AI-Native Development Platforms: entornos de desarrollo donde agentes de IA colaboran con humanos para crear software en tiempos récord.
• Multi-Agent Systems (MAS) y Domain-Specific Language Models (DSLMs): modelos que cooperan entre sí y entienden el contexto del negocio para resolver problemas complejos.
• AI Security Platforms: soluciones que centralizan el control sobre modelos, datos y prompts, anticipando amenazas antes de que ocurran.
• Geopatriación de datos: migración hacia nubes soberanas para reducir riesgos políticos y regulatorios.

El Cambio de Paradigma en 2026 

El análisis de Cloud Legion identifica tres pilares donde la innovación y la responsabilidad convergen:

1. De la IA “Añadida” a la IA “Nativa”: Ya no basta con integrar herramientas de IA en procesos viejos. Las AI-Native Development Platforms implican que el software se diseñará pensando en que agentes autónomos lo operen y aseguren. Cloud Legion observa que esto reduce el “time-to-market”, pero aumenta la superficie de ataque si no hay una gobernanza clara sobre el código generado por máquinas.
2. La Crisis de la Verdad (Deepfakes y Procedencia): La saturación de contenidos sintéticos hará que la “confianza” sea el activo más caro. Cloud Legion analiza que las empresas deberán implementar sistemas de atestación digital para demostrar que sus datos y comunicaciones son legítimos, protegiendo así su reputación de marca.
3. Soberanía Tecnológica (Geopatriación): Ante la fragmentación geopolítica, el análisis sugiere que las empresas deben ser capaces de mover sus cargas de IA entre nubes soberanas rápidamente para evitar bloqueos regulatorios o riesgos de espionaje industrial.

“Las empresas ya no pueden limitarse a reaccionar ante los ataques. La ciberseguridad de 2026 será predictiva, contextual y colaborativa. En Cloud Legion estamos desarrollando soluciones que integran IA defensiva, monitoreo continuo y resiliencia en la nube para acompañar esta evolución”, afirmó Luciano Moreira da Cruz, Chief Transformation & Strategy Office (CTSO) de Cloud Legion.

El reporte también advierte sobre la necesidad de verificar la procedencia digital de los contenidos generados por IA, en un entorno saturado de deepfakes y código automatizado. La confianza será un activo estratégico.

Cloud Legion recomienda a las organizaciones: (una hoja de ruta dividida en tres niveles de urgencia)

Nivel Operativo: Blindaje de la IA (Capa de Seguridad)

• Implementar AI Security Platforms (AISPs): No trate a la seguridad de la IA como seguridad IT tradicional. Necesita herramientas que monitoreen el drift (desviación) de los modelos, eviten el “Prompt Injection” y aseguren que los datos de entrenamiento no sean contaminados.
• Inventario de Agentes: Documentar qué sistemas multiagente (MAS) están operando en la empresa y bajo qué permisos, para evitar “acciones en cascada” no autorizadas entre modelos.

Nivel Táctico: Evolución de la Infraestructura

• Prepararse para la Supercomputación Híbrida: Evaluar proveedores que ofrezcan chips neuromórficos o arquitecturas GPU escalables para no quedar rezagados en capacidad de procesamiento frente a la competencia.
• Estrategia de Datos “Limpia”: Antes de adoptar modelos de lenguaje específicos de dominio (DSLMs), asegúrese de que sus datos internos estén curados y etiquetados. La IA es tan buena como la calidad de su contexto.

Nivel Estratégico: Cultura y Gobernanza

• Comités de Ética Operativos: Crear células de decisión integradas por expertos en legal, ciberseguridad y negocio para validar cada nuevo despliegue de IA desde el diseño (Security & Ethics by Design).
• Capacitación en “Humano-en-el-Bucle” (HITL): Entrenar al personal no para que vigile a la IA, sino para que colabore con ella, manteniendo siempre la capacidad humana de intervenir y corregir decisiones automatizadas.

Leer el artículo en Cloud Legion

Voy a contar qué hago, no qué dice la ley en abstracto. Para eso ya hay miles de artículos.

Mi secuencia

Primero, clasifiqué cada uso de Copilot por categoría de riesgo del Act. La mayoría caen en “limited risk” (transparencia hacia usuarios) o “minimal risk” (sin requisitos específicos). Pero algunos casos cayeron en “high risk” — análisis de CVs en procesos de selección, evaluación de empleados, soporte en decisiones de crédito. Esos tienen obligaciones serias.

Segundo, documenté. EU AI Act exige documentación de sistemas. Para Copilot empresarial estándar, Microsoft te da buena parte. Pero para tus agentes custom (los que creas en Copilot Studio con conectores a tus sistemas), la documentación la haces tú. Cada agente custom tiene su ficha: propósito, datos que usa, modelo subyacente, límites, supervisión humana, métricas de calidad.

Tercero, transparencia. Marqué a usuarios cuándo están hablando con un agente y cuándo con un humano. Suena obvio. No lo era. Tenía agentes en Teams que respondían sin marca clara. Lo cambié en Q1.

Cuarto, supervisión humana donde toca. Para los casos high-risk, ningún agente decide sin revisión. La revisión es real, no rubber-stamp. Métricas: porcentaje de decisiones revisadas vs aprobadas automáticamente. Si la revisión es 100% aprobar, no es revisión.

Quinto, evaluación de impacto. Los Fundamental Rights Impact Assessments para sistemas high-risk son nuevo trabajo. No es opcional. Mi equipo de legal trabaja con seguridad para producirlos. La primera vez tomó tres semanas. La segunda, una.

Lo que me ayudó

In-country processing en EU. Cuando Microsoft anunció procesamiento dentro de territorio europeo, marcó una casilla importante de cumplimiento. No la única, pero importante.

Microsoft Purview Compliance Manager. Tiene templates específicos para EU AI Act que dan la línea base de controles. Útil como punto de partida, no como punto de llegada.

Lo que no me ayudó

Los proveedores que prometen “compliance EU AI Act in a box”. No existe la caja. Compliance es proceso, no producto.

¿Recomendación si estás empezando? No esperes. La documentación de sistemas existentes es lo más lento. Si arrancas hoy, llegas. Si arrancas en seis meses, no.

Leer el artículo en Cloud Legion

Antes de AI-SPM, gobernar la postura de IA en una organización mediana era un trabajo de patchwork. Tenía que sumar señales de Azure OpenAI (qué deployments, con qué configs, con qué key management), Copilot Studio (qué agentes, con qué connectors), Foundry (qué modelos custom, con qué evaluaciones), agentes locales (qué corre, con qué permisos) y frameworks custom (lo que tu equipo de dev haya montado). Cada uno con su consola, su lógica, su nomenclatura. Cinco fuentes, cinco hojas de Excel, una visión turbia.

AI-SPM lo unifica. Un dashboard. Un secure score. Una vista por workload de IA con severidades, recomendaciones, owners.

Lo que más me ayudó al activarlo

La visualización de dependencias. AI-SPM dibuja qué workloads de IA dependen de qué identidades, qué datos, qué APIs externas. Cuando vi por primera vez el grafo, encontré dos workloads que dependían de una API externa que el equipo había puesto sin pasar por el proceso de aprobación de proveedores. Conversación incómoda con el dev, pero corregido en la semana.

La detección de configuraciones débiles. Modelos sin rate limiting, deployments con keys que llevaban meses sin rotar, conectores con permisos sobredimensionados. El secure score no es solo número — es una lista accionable de cosas que arreglar.

La integración con incidents en Defender XDR. Cuando un ataque toca la superficie de un workload de IA, ya no es solo “alerta del modelo” en una consola y “alerta de identidad” en otra. Es un incidente único correlacionado.

Lo que me sorprendió en mal

El cobertura todavía es desigual entre workloads. Azure OpenAI lo cubre bien. Copilot Studio aceptable. Frameworks custom — depende mucho de cómo los hayas instrumentado. Si no instrumentas, AI-SPM no ve. Esto es razonable técnicamente, pero genera ilusión de cobertura cuando el dashboard se ve “verde”. Verde en lo que ve. No verde en lo que no ve.

Los benchmarks de “secure score” son a veces optimistas. Un workload con score 85% puede tener gaps que importan en tu contexto pero que no se ven en el score. El score es punto de partida, no la métrica final.

La latencia de los signals: algunos hits tardan minutos en aparecer en el dashboard. Para detección casi tiempo-real, todavía hay que ir a Defender XDR directo.

Mi rutina con AI-SPM

Semanalmente: review del secure score y de los hallazgos abiertos. Asignación a dueños. Tracking de cierre.

Al onboarding de un workload de IA nuevo: chequeo previo de cobertura. Si no aparece en AI-SPM, lo instrumento antes de promover. La instrumentación a posteriori siempre se queda a medias.

Trimestralmente: presentación al board. AI-SPM da las gráficas que necesito. Score por workload, evolución temporal, top 5 hallazgos críticos. Antes preparar esto era media semana de trabajo. Ahora son veinte minutos.

Para quién es

Si tienes 10 o más workloads de IA distribuidos, AI-SPM cambia tu vida. Si tienes 2 o 3, probablemente con dashboards de Azure OpenAI normales te bastaba. La inversión en gobernanza unificada se justifica con escala.

¿Sustituye al programa de seguridad? No. Es la consola, no el programa. Las decisiones, los procesos, las personas — eso no lo da AI-SPM. Lo que da es la vista para tomar mejores decisiones.

Mi métrica favorita después de seis meses con AI-SPM activo: tiempo medio entre el deploy de un workload nuevo y la primera revisión de seguridad sobre él. Bajó de 23 días a 4. Eso es lo que me dice que la herramienta vale.

Leer el artículo en Cloud Legion

Voy a contar qué aprendí los primeros meses con CCS abierto en mi pestaña.

El problema que resuelve

Antes de CCS, gobernar Copilot era un viaje por cinco consolas. Microsoft 365 admin center para algunas configuraciones. Purview para sensitivity labels y DLP. Entra para identidades. Defender para alertas. SharePoint admin para SAM. Y a veces Copilot Studio aparte. Pasaba mucho tiempo recordando dónde estaba cada cosa. Mis screenshots de hace seis meses están llenos de capturas de “lo configuré en algún sitio que no recuerdo”.

CCS junta todo en una vista. Settings de Copilot, agentes registrados, políticas activas, alertas, reportes. No es que mueva lo que existía — sigue existiendo en sus consolas originales. Es que te da un agregador. Si quieres ir a la consola de origen, hay deep links. Si quieres operar desde CCS, las cosas más comunes están ahí.

Lo bueno

La adopción. Mi equipo de IT, que antes pateaba el tema de Copilot a otros, lo adoptó porque les bajó la fricción. Cuando algo se ve fácil de operar, se opera. Esa es la parte humana del problema.

La integración con Purview. Ver el dashboard de DLP de Copilot dentro de CCS, sin saltar, con los mismos filtros que estás usando, es una pequeña victoria. Pequeñas victorias suman.

El reporting agregado. Antes preparar un reporte mensual de “estado de Copilot” me llevaba dos días. Ahora tarde una mañana. CCS exporta gráficas decentes que pego directo en el deck.

Lo no tan bueno

Hay funciones que dicen estar “integradas en CCS” pero al hacer click te mandan al portal original. Engaño parcial. Lo más reportado: configuración de tenant settings avanzados que sigue forzándote a abrir el admin center clásico. Microsoft dice que están unificando. Mientras tanto, el deep link es lo que tienes.

Cargas lentas en algunas vistas. Cuando tienes muchos agentes registrados (yo tengo 60 ya), algunas listas tardan. Lo paliable, no bloqueante.

La curva de aprendizaje sigue siendo dura para alguien sin contexto. CCS no es una herramienta para principiantes en Copilot. Da por hecho que entiendes el modelo de licenciamiento, las identidades de agente, las políticas de DLP. Si llegas verde, te ahogas.

Lo que cambié en mi rutina

Reemplacé tres dashboards custom que tenía hechos en Power BI con vistas nativas de CCS. Los borré. Menos código que mantener.

Subí la frecuencia de mis check-ins. Cuando el dashboard está a un click, lo abres más. Antes lo miraba semanalmente. Ahora cada lunes y miércoles, mínimo.

Le pasé el acceso a CCS a dos managers que antes no entraban a herramientas de seguridad. La idea: que vean el estado de los agentes en sus áreas. Funcionó. Empezaron a hacer preguntas que antes no hacían. La governance distribuida pasa cuando la información se distribuye.

¿Es la solución definitiva? No. Es una capa de presentación encima de un stack que sigue siendo complejo. Si esperas que CCS te resuelva la complejidad de gobernar Copilot, vas a sentirte engañado. Si esperas que te baje la fricción operativa para administrar lo que ya entiendes, lo logras.

Mi puntuación honesta: 7 sobre 10. Le sobra trabajo. Pero es la dirección correcta y se ve que Microsoft le pone foco. Para Ignite 2026 espero un CCS más maduro. Por ahora, mejor con él que sin él.

Leer el artículo en Cloud Legion

La cínica primero. Microsoft estaba teniendo dificultades para vender Security Copilot como SKU separado. El precio por unidad de capacidad era alto, los pilotos tardaban en convertir, los CISOs miraban los números y dudaban. Incluirlo en E5 baja la barrera de entrada a cero — ya pagaste, úsalo.

Hasta ahí, marketing clásico.

Lo que cambia mi opinión es lo que viene con eso.

Security Copilot incluido no es la versión completa. Es un derecho de uso con un cupo de SCUs (Security Compute Units) razonable para casos de uso medianos. Si tu SOC corre operaciones grandes, te quedas corto rápido y vuelves al modelo de pago. Pero para muchas organizaciones — especialmente las que aún no tenían Security Copilot — el cupo incluido alcanza para empezar.

Y empezar es lo importante. Microsoft está apostando a que, una vez que pruebes los Security Copilot agents en Defender, Entra, Intune y Purview, no quieras volver atrás. Los agentes nuevos — los doce que anunciaron — atacan dolores reales del SOC.

Los que más he probado

El agente de phishing triage en Defender. Antes tenías a un analista de tier 1 dedicado a clasificar correos reportados. Ahora el agente preclasifica, y el analista mira los casos no triviales. En el equipo donde lo metí, el tiempo medio de resolución bajó del orden del 60%. No es magia. El agente comete errores. Pero la mayoría de su trabajo es bueno y los humanos pueden enfocarse arriba.

El agente de optimización de Conditional Access en Entra. Mira tus políticas, encuentra duplicaciones, sugiere consolidaciones. La primera vez que lo corrí en mi tenant, identificó cuatro políticas que se contradecían entre sí. Llevábamos meses con esa contradicción y nadie la había visto.

Si no tienes E5 todavía

Esta es la conversación interesante. Antes de Ignite 2025, justificar el upgrade a E5 era difícil para muchas empresas — el delta de funcionalidades sobre E3 más addons no siempre era claro. Con Security Copilot incluido, el balance cambia. Es una pieza más en la columna del “vale la pena”.

Mi cálculo aproximado para una empresa de 1,000 empleados: el ahorro en SCUs gratuitas más el valor de los agentes en SOC, si los usas, suele cubrir el delta de E5 contra E3. No siempre. Depende de tu uso. Pero ya no es claramente negativo, como sí lo era antes.

Si ya tienes E5 pero no habías tocado Security Copilot

Empezar con un piloto enfocado, no con toda la suite. Mi recomendación: arranca con dos agentes, no con doce. Phishing triage en Defender más uno relevante para tu mayor dolor (Conditional Access en Entra, Identity Risk en Entra, o el que sea). Mide. Después expande.

No prendas todos los agentes de un golpe. Te van a saturar con alertas y configuraciones. Y tu cupo de SCUs se gasta más rápido de lo que te imaginas si dejas todo corriendo.

Lo que no me gusta del cambio

Que Microsoft no fue claro sobre el cupo exacto incluido al principio. Costó leer la letra chica. Hoy está mejor documentado, pero al inicio había confusión sobre qué era “incluido” y qué era “consumido” en SCUs.

Que el reporting unificado de uso entre los distintos agentes todavía no es perfecto. Cuando llega final de mes, ver quién consumió qué requiere paciencia.

Que el modelo crea dependencia. Una vez que el SOC se acostumbra a tener agentes ayudando, sacarlos es doloroso. Microsoft sabe esto. Apuesta a que tu uso crezca y termines pagando SCUs adicionales. Es un negocio bien diseñado.

¿Recomendación final? Si tienes E5 y no has tocado Security Copilot, pruébalo este mes. No mañana. La curva de aprendizaje del equipo es lo más caro, y cuanto antes empieces, antes capitalizas.

Leer el artículo en Cloud Legion

Para mí es una de las decisiones más importantes del año en este espacio.

Dejame contar por qué.

La pelea regulatoria sobre dónde se procesan los datos no es nueva. EU Data Boundary, que existe desde 2023, ya garantizaba almacenamiento en territorio europeo para servicios de Microsoft 365. Pero los servicios de IA tienen una particularidad: el procesamiento puede salir del territorio aunque el almacenamiento no. La inferencia se hacía donde estuviera disponible la GPU. Y las GPUs estaban concentradas en pocos sitios.

Para muchos sectores regulados — banca, salud, gobierno, defensa — eso no era suficiente. “Tus datos se almacenan en mi país pero la IA piensa con ellos en otro”. Los reguladores empezaron a apretar. En 2025 vi RFPs con cláusula explícita: “el proveedor debe garantizar procesamiento de IA en territorio nacional”. Microsoft lo escuchó.

In-country processing no es un cambio de marketing. Es un cambio de infraestructura. Microsoft tuvo que desplegar capacidad de inferencia regionalizada — GPUs, modelos, redes de baja latencia — en cada uno de los 15 países anunciados. La ingeniería detrás es seria.

Qué cambia para mí como cliente

Cumplimiento más limpio. Si tu regulador local exige procesamiento doméstico, tienes una respuesta documentada. Antes era “tenemos almacenamiento en su jurisdicción y procesamiento en la región más cercana”. Ahora es “todo doméstico”. Eso ahorra meses de back-and-forth con compliance.

Latencia mejor en algunos casos. Si tu organización está físicamente lejos del datacenter principal, ver inferencia local es notable. En la prueba que corrí en India, la latencia bajó cerca de un 40% en prompts complejos.

Trazabilidad más simple. Logs de inferencia con jurisdicción explícita. Para auditorías, es oro.

Qué no cambia

El modelo sigue siendo el mismo. La calidad de respuestas no es distinta por región. Si esperabas un modelo “específico de tu país”, no es eso lo que pasa.

Las críticas justas

“Microsoft sigue siendo una empresa estadounidense, así que el CLOUD Act sigue aplicando aunque el dato se procese localmente”. Cierto. La soberanía completa solo la consigues con un cloud soberano completo (que existe, en algunos países, con acuerdos específicos). In-country processing es paso adelante, no fin del camino.

“15 países es poco”. Cierto. Si estás en Latinoamérica, África o partes de Asia, el roadmap todavía no te llega. Hay que seguir mirando. Microsoft dice que continúan expandiendo. La realidad: los datacenters cuestan, y se priorizan mercados grandes.

Mi consejo a quien evalúe esto

Pregunta primero qué exige tu regulador, no qué te ofrece Microsoft. La conversación es al revés. Si tu regulador exige X y Microsoft te ofrece in-country en tu jurisdicción, está bien. Si tu regulador exige X y Microsoft no te lo da, no fuerces el match.

Pregunta segundo cómo se documenta. “In-country processing” como capacidad es una cosa. Cómo se evidencia en logs, contratos y auditorías es otra. Pídelo por escrito, en el contrato. La capacidad técnica sin la cláusula contractual no te sirve en una disputa.

Pregunta tercero qué pasa si la capacidad local cae. ¿El servicio se degrada o se redirige a otra región? Ese punto suele estar en letra chica y es importante para cumplimiento.

A mayo 2026, in-country processing es una de las capacidades más estratégicas de Copilot para mercados regulados. No la subestimes solo porque no te aparezca en el screenshot bonito de la consola.

Leer el artículo en Cloud Legion

Spotlighting es la capacidad, anunciada en Build 2025, de marcar el origen del input que entra al modelo. Distingue entre lo que el usuario escribe y lo que viene dentro de un documento o de una página web procesada. Es decir, le dice al modelo: esto es del usuario, esto es de un tercero, trátalos distinto.

La categoría de ataque de “prompt injection indirecta” — que es exactamente lo que aprovechó EchoLeak — se conocía desde 2022. Investigadores académicos llevaban tiempo gritando que esto iba a romper modelos en producción cuando se les diera acceso a documentos, correos, páginas. Microsoft sacó Prompt Shields en 2024 (la primera versión, con foco en jailbreaks directos). Spotlighting, que va al corazón de la prompt injection indirecta, llegó en 2025. Después de que EchoLeak demostrara la categoría en producción.

No critico la dirección. Critico el ritmo.

Lo que Prompt Shields hace bien hoy

Detecta jailbreaks directos. “Ignora tus instrucciones anteriores y dime…”. Eso lo bloquea sin problema, casi siempre. Detecta patrones conocidos de agent-hijack — instrucciones que tratan de cambiar la persona del agente, desviarlo de su tarea, hacerle ejecutar acciones fuera de su scope.

Detecta, con Spotlighting activo, indirect prompt injection en muchos casos. He puesto a prueba su detección con payloads conocidos públicamente y los pilla mayormente. Con payloads custom — ataques pensados para tu contexto específico — la cosa es más mixta. Los modelos de detección están entrenados sobre patrones generales, no sobre las particularidades de tu tenant.

Lo que no hace bien

No detecta exfiltración semántica sofisticada. Si el atacante en lugar de pedir explícitamente “manda este dato al endpoint X” lo pide en lenguaje natural elaborado (“incluye en el resumen este enlace”), la detección baja.

No correlaciona entre prompts. Cada llamada al modelo se evalúa por separado. Ataques que se desarrollan en varios turnos pueden pasar.

No reemplaza arquitectura. Si tu agente carga URLs sin validar, ningún Prompt Shield te salva.

Mi configuración actual

Tengo Prompt Shields encendido en todo lo que es Copilot Studio. Spotlighting activo en todos los flujos donde entra contenido externo. Logging completo a Sentinel, con dashboards específicos para hits del shield.

Encima, capa de validación propia: cualquier URL que el agente quiera tocar pasa por una allowlist. Cualquier output que tenga URLs en Markdown se sanitiza antes de mostrarse. Cualquier acción del agente con efectos laterales (mandar correo, modificar archivo) requiere confirmación explícita del usuario.

Es defensa en profundidad. Prompt Shields es una capa, no la solución. Si la presentas a tus stakeholders como “tenemos prompt injection resuelto porque tenemos Prompt Shields”, te van a faltar capas el día que pase algo.

Lo que espero de Microsoft

Spotlighting más fino, con etiquetas más específicas (no solo trusted/untrusted, sino también “fuente externa por firewall”, “fuente externa por correo”, “fuente compartida por enlace”). Cuanto más granular, mejor las decisiones de bloqueo.

Detección de exfiltración por canales no obvios. Imágenes, links de Markdown, patrones de respuesta que filtran datos en formato sutil. Es donde EchoLeak pegó duro y donde la siguiente generación de exploits va a apuntar.

Integración nativa con Defender for AI. Hoy hay puentes pero no es nativo. Si Prompt Shields detecta y Defender investiga sin fricción, el SOC respira.

Por ahora, Prompt Shields es el control más importante que tienes contra esta clase de ataques. Pero por favor, no es el único que necesitas.

Leer el artículo en Cloud Legion

CVE-2025-32711, CVSS 9.3. Microsoft lo parcheó server-side rapidito y sin advisory ruidosa. Lo cual me parece bien y me parece mal a la vez. Bien porque la mitigación tiene que ser inmediata. Mal porque sospecho que muchos equipos de seguridad ni se enteraron de la magnitud hasta que los investigadores publicaron el detalle en arXiv unos meses después.

Lo que más me marcó del writeup es la elegancia del exploit. No es un bug. Es una cadena.

Primero, evade el clasificador XPIA (Cross Prompt Injection Attempt) usando lenguaje que no se ve como instrucción adversaria. Después esquiva la redacción de enlaces con Markdown reference-style (en lugar de poner el enlace con el dato sensible directo, lo separa en una referencia). Después usa imágenes que se auto-fetchean — el simple acto de cargar la imagen ya filtra el dato porque la URL lleva la información. Y el cierre de oro: abusa de un proxy de Teams que está permitido por la Content Security Policy. Filtración limpia.

Lo bauticé en mi cabeza como “el vector que demuestra que la CSP de tu app no es suficiente cuando metes un LLM en medio”. Porque eso es lo que es. La CSP estaba bien para una app tradicional. Para una app que tiene un agente que decide a qué dominio se conecta, la CSP es solo el principio.

Qué hago yo distinto desde EchoLeak

Lo primero, asumo que cualquier dato no estructurado que Copilot toque es input no confiable. No solo correos de fuera. También documentos compartidos por terceros, también notas pegadas de quién sabe dónde. Eso ya cambia cómo configuro las políticas de DLP.

Segundo, miro con otros ojos las funcionalidades de “auto-summarize”. Cualquier cosa donde Copilot procese contenido sin que yo le pida explícitamente que lo haga es vector. Es ahí donde EchoLeak metió la cuchilla.

Tercero, y esto es opinión: creo que Microsoft tardó en sacar Spotlighting. Lo anunciaron en Build 2025, pero la categoría de ataque ya se conocía. Spotlighting marca el origen del input para que el modelo distinga “esto me lo dijo el usuario” de “esto venía dentro de un documento”. Era un control que necesitábamos antes, no después.

Para mi equipo hicimos tres cosas concretas las semanas siguientes. Auditamos qué buzones tienen reglas de auto-procesado que terminen llegando a Copilot — apagamos varias. Forzamos sensitivity labels en todo lo que viene de invitados externos: si entra etiquetado como external, Copilot no lo procesa. Y activamos logging completo de prompts en Purview, aunque pesa un montón. Sin auditoría no hay forensia.

Lo último — y esto es lo que me sigue rondando — es que EchoLeak no fue un fallo en un modelo grande. Fue un fallo en cómo Microsoft pegó el modelo al resto del stack: identidades, permisos, cargas de URL, parsers de Markdown. La superficie de ataque del Copilot empresarial no es el LLM. Es la conexión del LLM con todo lo demás.

El día que entendí eso fue el día que dejé de ver a Copilot como un producto y empecé a verlo como una integración compleja. Y las integraciones complejas se rompen en las costuras.

Leer el artículo en Cloud Legion

Microsoft sacó el AI Red Teaming Agent en Foundry para cambiar eso. La promesa: red team automatizado, escalable, repetible. La realidad: útil, no sustituto.

Lo probé en serio este trimestre, contra dos agentes de Copilot Studio que tengo en producción ligera. Voy a contar lo que vi.

Qué hace

El agente toma tu agente bajo prueba y le tira payloads adversarios desde una librería curada. Cubre prompt injection directa, indirecta, jailbreak, content harms, tool abuse, agent hijack. La librería se actualiza. También permite cargar payloads custom, así que si tienes tu propio dominio (financiero, salud, legal), puedes meter ataques específicos.

Te entrega un reporte: qué payload pasó, qué se bloqueó, qué generó respuestas problemáticas. Métricas, severidades, sugerencias de mitigación.

Lo bueno

Velocidad. Mil ataques en una hora. Un humano hace cien en un día bueno. La cobertura amplia es donde brilla. Si tu agente tiene un patrón de fallo conocido, casi seguro lo encuentra.

Repetibilidad. Cada nueva versión de tu agente la pasas por la misma batería. Detectas regresiones. CI/CD para seguridad de IA. Esto es lo que más me cambió: meter el red teaming en el pipeline, no como ejercicio anual.

Integración con Foundry. El reporting fluye al mismo lugar donde llevas el resto de tus pruebas y safety evaluations. Vista única.

Lo no tan bueno

Encuentra ataques conocidos. Brilla menos con ataques nuevos, sutiles, específicos a tu dominio. Si tienes un caso de negocio peculiar, los payloads genéricos no van a detectar todos los caminos. Necesitas un humano experto que escriba payloads específicos a lo tuyo. El agente automatiza lo conocido, no lo creativo.

La interpretación de resultados sigue requiriendo expertise. Reporte que te dice “12 ataques pasaron, 88 bloqueados”. OK. ¿Cuáles son los 12? ¿Cuáles importan más? Eso lo tienes que entender tú o alguien con criterio.

Falsos positivos pasan. A veces el agente clasifica un comportamiento como problemático cuando es esperado en tu caso. La triangulación con un humano es necesaria.

Cómo lo uso

Para regresiones: parte del pipeline. Cada cambio de prompt, cada nuevo conector, cada update del modelo, batería completa. Si la baseline empeora, alerta antes de promover a producción.

Para baseline en agentes nuevos: antes de meter un agente nuevo a producción, ejercicio completo. Si pasa los ataques conocidos, listo el primer filtro. Después le sigo con red team manual sobre lo específico de mi dominio.

Para auditoría: el reporte automatizado es excelente evidencia para auditores externos. “Aquí está el resultado de la batería de pruebas adversarias contra cada agente, ejecutada cada N días”. Antes esto era difícil de producir. Ahora es un export.

Lo que me gustaría que tuviera

Más payloads en español. La librería está fuerte en inglés y los modelos modernos transfieren razonablemente, pero los ataques en español tienen sutilezas. Espero que la librería se siga internacionalizando.

Soporte mejor para agentes multi-step complejos. Los ataques que se desarrollan a lo largo de varios turnos, con planificación, son más difíciles de automatizar. Hoy detecta lo turn-by-turn bien, lo multi-turno con menos profundidad.

Integración nativa con MCP. La capacidad de probar agentes que usan MCP servers externos. Esto es un gap. Hoy si tu agente usa MCP, la cobertura del red team baja porque no entiende del todo las superficies extra. Espero ver mejoras en los próximos meses.

¿Es suficiente? No. Es parte del programa de seguridad, no el programa entero. Pero es un avance gigante respecto a hace dos años, donde literalmente no existía esta categoría de herramienta.

Si tienes agentes en producción y no estás haciendo red teaming sistemático sobre ellos, es la pieza que más rápido te baja el riesgo. Hazlo ahora.

Leer el artículo en Cloud Legion

Los esquemas que se diseñaron antes de Copilot tienen un sesgo: están pensados para humanos clasificando documentos. Cinco niveles, descripciones largas, instrucciones que el usuario teóricamente lee al elegir el label. En la práctica, el usuario clica el primero que ve y sigue. Cuando Copilot empieza a actuar sobre esas etiquetas, los problemas afloran.

Mi taxonomía actual, después de tres iteraciones

Cuatro niveles, no más. Más de cuatro y la gente se confunde. Public, Internal, Confidential, Restricted. Cada nivel con un sub-marcador opcional (“External-Allowed” o “External-Blocked”). El sub-marcador ataca el problema de “es confidencial pero el partner X sí lo puede ver”.

Reglas claras de procesamiento por Copilot. Cada label tiene una regla explícita: ¿Copilot puede leer? ¿Puede generar contenido derivado? ¿Puede compartir en la respuesta a un usuario externo invitado? La matriz cabe en una página.

Auto-labeling agresivo en lo trivial. SSN, números de tarjeta, IBANs, datos de RRHH conocidos — auto-label sin pedirle al usuario. La auto-classification de Purview es buena. Confío en ella para el 70% del corpus. El 30% restante lo etiqueta el usuario.

Defaults razonables. Si un sitio nuevo se crea sin label, hereda “Internal” por política. Antes era “Public” por descuido. Eso solo bajó mi superficie de exposición en un 12%.

Lo que aprendí en el camino

Que un label complicado se ignora. La gente no quiere leer. La gente quiere clicar.

Que los labels por sí solos no protegen. Un label sin DLP detrás es un papel en la pared. Yo combino label más DLP más Conditional Access. Las tres capas o ninguna.

Que migrar es doloroso. Tuve documentos con label viejo, documentos con label nuevo, documentos sin label. Tomó cuatro meses migrar el corpus crítico. Los demás documentos los seguimos limpiando. La perfección es enemiga del progreso.

Que Copilot acelera la limpieza. Cuando un usuario pregunta a Copilot por algo y la respuesta se bloquea por DLP, el usuario reporta. Cada bloqueo es feedback. Cada feedback me dice qué documentos tienen el label mal puesto. La operación de Copilot se vuelve auditoría continua del esquema de labels.

¿Lo recomendaría? Sí, pero con expectativas reales. Diseñar bien lleva semanas. Implementar lleva meses. Madurar lleva un año. Si tienes Copilot en piloto y sensitivity labels todavía sin definir, no demores. La complejidad solo crece.

Leer el artículo en Cloud Legion

Customer Lockbox de Microsoft es el mecanismo por el cual, si un ingeniero de Microsoft necesita acceso a tus datos para soporte técnico, tú apruebas o rechazas la solicitud. Tu dato no se toca sin tu OK. Es una de las garantías que más vendí en los últimos años a clientes nerviosos por privacidad.

Qué pasa con Copilot

Para datos almacenados en Microsoft 365 (correo, archivos en SharePoint y OneDrive, mensajes de Teams), Customer Lockbox aplica como siempre. Si un ingeniero de Microsoft necesita revisar uno de esos datos para resolver un problema de Copilot, requiere tu aprobación.

Para los datos en tránsito en el procesamiento de Copilot — el prompt que el usuario manda, la respuesta generada — la situación es distinta. Esos datos viven en el plano de inferencia. Customer Lockbox no aplica de la misma forma. Microsoft documenta que prompts y respuestas no se usan para entrenar y se eliminan según retención. Pero el modelo de Customer Lockbox tradicional no se extiende todavía con el mismo rigor.

Para los logs de Copilot (qué pidió cada usuario, qué respondió el modelo) que se almacenan en Purview con tu retención — eso vuelve a ser dato tuyo y Customer Lockbox aplica.

Esto no es un gap de seguridad. Es un gap de garantía formal de control de acceso operativo.

¿Importa?

Depende de tu industria. Para banca o salud altamente regulado, el modelo “Microsoft no toca mis datos sin que yo apruebe” es importante. Si Customer Lockbox no cubre prompts en tránsito, tienes que documentar el gap y mitigarlo de otra forma — confidential compute, o aceptar el control compensatorio del acuerdo contractual con Microsoft.

Para la mayoría de empresas, no es un blocker. Microsoft tiene controles internos robustos, attestations independientes, y el modelo de procesamiento de Copilot no es de “ingenieros viendo prompts”. Es automatizado.

Qué hago yo

Primero, no vendo Customer Lockbox como garantía total para Copilot. Sería deshonesto. Vendo lo que aplica y soy claro sobre lo que no.

Segundo, para clientes muy regulados, busco alternativas: Confidential Compute donde está disponible, in-country processing donde aplique, contratos específicos donde el riesgo lo justifica.

Tercero, monitoreo. Microsoft mejora estas garantías con el tiempo. Customer Lockbox para AI services es área activa. Espero updates en los próximos 6 a 12 meses.

Resumen para no técnicos: Customer Lockbox es real para tus datos almacenados. Para el procesamiento de IA en sí, hay garantías distintas pero no Customer Lockbox como tal. Léelo en el contrato, no en el marketing.

Leer el artículo en Cloud Legion

SAM no es nuevo. Lo que es nuevo es que ya no tienes excusa para no usarlo si tienes Copilot.

Para quien no lo conozca: SAM (SharePoint Advanced Management) es un paquete de capacidades de governance para SharePoint. Inactive sites detection, oversharing reports, data access governance reports, conditional access policies a nivel de site, restricted access control. Una colección de cosas que viven en distintos rincones del admin center pero apuntan al mismo problema: tu SharePoint creció sin gobierno y ahora hay que ordenarlo.

El primer reporte

Cuando lo activé por primera vez en mi tenant, el reporte inicial fue, cómo decirlo, humillante.

Sitios inactivos con datos sensibles: 1,247. Sitios con permisos rotos (heredados pero el padre se borró): 89. Sitios con “Everyone except external users” en el grupo de Members: 312. Sitios sin propietario asignado válido (el dueño ya no estaba en la empresa): 56.

Y eso solo en la primera pasada. La segunda, con filtros más finos, sacó otra capa.

Lo que hice con esos datos

Para sitios inactivos: política nueva. Si no se accede en 90 días, archive workflow. Si nadie reclama en 30 días más, archivado. Si nadie reclama en 180 días desde el archive, candidato a eliminación. SAM permite automatizar buena parte de eso con políticas. La parte humana — confirmar con dueños — la tienes que orquestar tú.

Para “Everyone except external users”: más doloroso. Cada uno requería un revisor. Lo que ayudó fue una matriz de criticidad de datos: qué tipo de contenido tiene cada sitio. Los críticos (legal, finanzas, RRHH) los atacamos primero, manualmente. Los menos críticos los atacamos en cohortes.

Para permisos rotos: SAM los identifica pero no los arregla. Hay que entrar uno por uno o usar PowerShell. Lo más eficiente para nosotros fue agruparlos por área y mandar un ticket por área al dueño funcional con la lista. Que ellos se hagan cargo. Y si en X días no se responde, escalado.

Lo que SAM no hace

No es DLP. SAM te dice quién tiene acceso. Purview DLP te dice qué se puede hacer con el contenido. Son complementarios.

No es scanning de contenido. SAM mira permisos y metadata. Si tienes un PDF con SSN dentro pero el archivo está en un sitio “limpio” en cuanto a permisos, SAM no te lo dice. Para eso, sensitivity labels más auto-labeling de Purview.

No es un sustituto de governance proactivo. SAM te ayuda a limpiar lo viejo. Si no cambias cómo se crean nuevos sitios — templates con permisos sensatos, dueños obligatorios, lifecycle defaults — vas a estar limpiando para siempre.

Mi flujo actual

Al inicio de cada quarter, corro reporte completo. Diff contra el quarter pasado. Métrica clave: ¿bajaron sitios con problemas, o subieron? Si subieron, política nueva no funcionó. Si bajaron, mantengo curso.

Mensualmente, alerta de nuevos sitios sin propietario. Estos son la fuente principal de problemas futuros. Reasignar al crear, no al limpiar.

Trimestralmente, review con cada área de sus sitios críticos. SAM da el dato, el área toma la decisión. La governance funciona si los dueños se sienten dueños.

Lo último que diría: SAM no resuelve nada por ti. Es luz, no acción. Si no asignas el tiempo a actuar sobre lo que la luz revela, mejor no la enciendas — porque entonces es solo evidencia documentada de que sabías y no hiciste nada. Y eso, en una auditoría, es peor que la ignorancia.

Leer el artículo en Cloud Legion

Copilot llegó y rompió la complicidad colectiva.

Los datos que más he citado este año vienen de un reporte de Concentric: 16% de los datos críticos de negocio están sobre-compartidos, con un promedio de 802 mil archivos en riesgo por organización. Yo en mi tenant medí algo parecido: 14% en una primera pasada. Ese 14% incluía nóminas, contratos con clientes, una carpeta entera de la junta directiva accesible a “Everyone except external users”. Que es básicamente “todo el mundo de la empresa”.

¿Por qué Copilot lo hace evidente? Porque acelera el descubrimiento. Antes, esos archivos solo aparecían si alguien sabía buscar el nombre exacto. Copilot, con prompt y contexto, los superficie. “Resúmeme lo que sepamos de la compensación del C-suite”. Y boom, te aparece un PDF de la junta que estaba mal compartido desde 2022.

Microsoft ha intentado dar herramientas. La principal es Restricted SharePoint Search, que ayuda a limitar qué sitios entran al pool de búsqueda de Copilot. Pero hay que leer la letra chica: Microsoft mismo dice que no es un control de seguridad. Es un control de visibilidad temporal. No cambia permisos. Y si un usuario entró al sitio recientemente o le compartieron un enlace por Teams, el sitio aparece igual. Restringir la búsqueda es ganar tiempo, no resolver el problema.

La solución de fondo es arreglar permisos. Lo cual nadie quiere oír.

Lo que me funcionó

Empecé por las “joyas de la corona” — conté con el dueño de cada función qué cinco repositorios le quitarían el sueño si se filtraran. Quince personas, setenta y cinco repositorios. Ahí concentré el primer esfuerzo. No traté de arreglar todo SharePoint en un trimestre porque no se puede.

Después usé SharePoint Advanced Management (SAM, viene incluido con Copilot) para la evaluación masiva. El reporte inicial es brutalmente honesto. Te enseña sitios inactivos con miembros que ya no están. Sitios con permisos heredados rotos. Sitios donde “Everyone” tiene Edit. Para varios equipos, esa visibilidad fue suficiente para que se pusieran a limpiar sin pelearse conmigo.

Después puse políticas defensivas: nada nuevo se crea con “Everyone except external” como permiso por defecto. Forzamos labels de sensibilidad en plantillas. Auditamos creaciones nuevas semanalmente.

Lo que no funcionó: tratar de “limpiar todo” con un script. Cada sitio tiene un dueño y una historia. Los scripts son útiles para encontrar problemas, no para resolverlos.

Lo que tampoco funcionó: meterle miedo a la gente con ejemplos hipotéticos. Lo que sí funcionó fue mostrar a un VP, en su pantalla, que su asistente podía hacer un prompt en Copilot y obtener información de su salario que no debería ver. Diez minutos. Esa demo aceleró tres meses de cleanup.

Mi conclusión a estas alturas: Copilot no creó el problema de oversharing. Lo aireó. Y eso es bueno, aunque duela.

Si yo te diera un solo consejo para tu siguiente reunión interna sobre este tema, sería este: deja de hablar de “permisos” y empieza a hablar de “dueño accountable de cada repositorio”. Cuando hay un nombre y apellido al lado de cada sitio, las cosas se mueven. Cuando es “el equipo de IT”, se quedan dormidas.

Leer el artículo en Cloud Legion

Tengo que escribir esto porque me pasa con demasiada frecuencia.

Restricted SharePoint Search hace una cosa muy concreta: limita qué sitios entran al pool que Copilot consulta y que aparece en búsqueda corporativa. Es un control de discoverability. Útil. No discuto que sea útil. Lo uso. Lo recomiendo.

Lo que no es

No es un control de seguridad. Microsoft mismo lo dice en la documentación oficial, en negritas. No cambia permisos. Si el archivo existía y el usuario tenía acceso antes, sigue teniendo acceso después.

No garantiza que un sitio fuera del allowed list no aparezca. Si el usuario tocó el sitio en los últimos N días, si se lo compartieron por Teams, si se lo enviaron por Outlook, ese sitio puede entrar al contexto igual. Microsoft lo documenta también, pero con menos negritas.

No es solución permanente. Microsoft lo presenta explícitamente como un parche temporal mientras arreglas permisos. La traducción del marketing al ingeniero es: úsalo mientras limpias, no como sustituto del cleanup.

Cómo lo usé en el rollout

Cuando hice el rollout de Copilot el año pasado, lo activé en día uno. Eso me dio algo de aire mientras montábamos el programa de remediación. Le metí 200 sitios al allowed list — los que sabíamos que estaban limpios y eran útiles. El resto quedaba excluido del pool por defecto.

Resultado bueno: la calidad de las respuestas de Copilot bajó al inicio. Era predecible — limitaste su contexto. Algunos usuarios protestaron. “Copilot ya no encuentra mis documentos”. Tuvimos que explicar que era temporal. Gestión del cambio que no se puede saltar.

Resultado malo: los falsos positivos de seguridad de algunos managers explotaron. “Yo le pregunté X y me sacó un PDF de un sitio que pensaba que estaba bloqueado”. Investigamos. Sí, el sitio estaba bloqueado en el allowed list. Pero el manager lo había abierto la semana anterior porque alguien le compartió un link. Copilot lo trajo del cache de actividad reciente del usuario.

Microsoft no está mintiendo cuando documenta esa limitación. Pero la mayoría de equipos no la entienden hasta que la viven.

Después de seis meses de cleanup serio (con SAM, Purview, y mucho café), pude empezar a quitar sitios del exclude. Hoy uso Restricted SharePoint Search con una lista mucho más permisiva, porque ya no necesito el dique. Tengo permisos correctos.

La trampa para nuevos usuarios

Se ve fácil de configurar. Lo activas, metes una lista, y parece que terminaste. Y por seis meses, todo parece estar bien. Hasta que un auditor te pregunta cómo garantizas el control. Y le tienes que decir, mirando al suelo, que no es un control de seguridad. Es un freno suave.

Mi recomendación práctica: trátalo como herramienta táctica de transición. Día 1 lo activas con allowed list pequeña. A medida que limpias permisos, expandes la lista. A los 12 meses, idealmente, ya no la necesitas, o la usas solo para áreas con compliance específico. Es un puente, no la torre.

Y, por favor, no le digas a tu C-suite que “tienes oversharing controlado” si tu única defensa es Restricted SharePoint Search. Porque cuando alguien encuentre el archivo equivocado y suba la queja, el reporte forense va a doler.

Leer el artículo en Cloud Legion

La Inteligencia Artificial (IA) está redefiniendo la seguridad digital y Microsoft está a la vanguardia con nuevas herramientas para proteger y optimizar este ecosistema.

El gigante tecnológico ha presentado un conjunto de mejoras para Microsoft Security Copilot , incluidos seis agentes especializados para la respuesta a incidentes y nuevas capas de protección para IA.

Agentes de IA para una seguridad más eficiente

Los nuevos agentes, disponibles a partir de abril, están diseñados para fortalecer la seguridad empresarial aprendiendo de los comentarios del equipo, integrándose en los flujos de trabajo y alineándose con el enfoque de Confianza Cero de Microsoft .

Estos agentes aceleran la respuesta ante amenazas, mejoran la gestión de riesgos y optimizan las soluciones de Microsoft, lo que garantiza un control total para los equipos de seguridad.

Los seis agentes se distribuirán en las principales plataformas de seguridad de Microsoft:

• Agente de clasificación de phishing (Microsoft Defender) : analiza y clasifica las alertas de phishing, diferenciando las amenazas reales de los falsos positivos y mejorando continuamente la detección.
• Agentes de triaje de alertas (Microsoft Purview) : supervisa incidentes relacionados con pérdida de datos y riesgos internos, priorizando los más críticos.
• Agente de optimización de acceso condicional (Microsoft Entra) : identifica brechas en las políticas de acceso y sugiere soluciones automáticas.
• Agente de remediación de vulnerabilidades (Microsoft Intune) : administra las vulnerabilidades y aplica parches de seguridad de manera más eficiente.
• Agente de información sobre amenazas (Security Copilot) : selecciona automáticamente información sobre amenazas relevante adaptada a la organización.

Además de los agentes internos, empresas asociadas como OneTrust, Aviatrix, BlueVoyant, Tanium y Fletch están desarrollando sus propias soluciones dentro del ecosistema de Security Copilot.

Protección de la IA: un desafío creciente

La seguridad de la IA está en la agenda de las organizaciones, pero un informe reciente de Microsoft revela que el 57% de las empresas ya enfrentan un aumento de incidentes debido a la IA, y el 60% aún no ha implementado medidas de control adecuadas.

Para mitigar estos riesgos, Microsoft ha anunciado nuevas funciones avanzadas:

• Microsoft Purview : presenta la funcionalidad de investigaciones de seguridad de datos , que proporciona un análisis en profundidad de la exposición de datos confidenciales y los riesgos asociados con incidentes.
• Microsoft Defender : ahora es compatible con Google Vertex AI y todos los modelos de Azure AI Foundry, lo que extiende la protección a un ecosistema más amplio.
• Microsoft entra en escena : aplica filtros al acceso web, reduciendo los riesgos asociados con la IA en la sombra .
• Microsoft Defender para Office 365 : fortalece la protección contra el phishing y las amenazas cibernéticas en Microsoft Teams.

Copiloto de seguridad de Microsoft

Al detectar 84 mil millones de señales de amenaza diariamente y 7000 ataques de contraseña por segundo, Microsoft está adoptando un enfoque de inteligencia artificial para la seguridad digital, creando un entorno más seguro para las organizaciones de todo el mundo.

Para obtener más información, consulte el blog oficial de Microsoft .

Leer el artículo en Cloud Legion

La nueva generación de herramientas automatizadas promete transformar la gestión de amenazas para organizaciones de todos los tamaños.

Microsoft realizó la mayor actualización de su plataforma Security Copilot con 11 agentes de IA especializados, diseñados para automatizar hasta el 80% de las tareas de seguridad tradicionales. Esta innovación estará disponible a partir de abril de 2025.

La implantación de este tipo de agentes permitiría a los usuarios reducir su riesgo cibernético sin ampliar su equipo; automatizar el cumplimiento normativo más complejo y proteger las inversiones en IA generativa.

Desde la perspectiva de la compañía, el establecimiento de agentes de IA es una necesidad para la seguridad moderna.

Microsoft Threat Intelligence ahora procesa 84 billones de señales por día, lo que revela el crecimiento exponencial de los ciberataques, incluidos 7 mil ataques de contraseñas por segundo.

Microsoft actualizó Security Copilot con seis agentes de seguridad creados por la compañía y cinco agentes de seguridad creados pors socios de negocio.

Los 6 agentes desarrollados por Microsoft tienen las siguientes funcionalidades:

Agente de Clasificación de Phishing (Defender)

1.                      Analiza 30 mil millones de correos sospechosos diarios

2.                      Reduce falsos positivos en un 65%

3.                      Ideal para: Empresas con alto volumen de correo electrónico

Agente de Priorización de Alertas (Purview)

1.                      Clasifica automáticamente incidentes de pérdida de datos

2.                      Reduce tiempo de respuesta en un 70%

3.                      Perfecto para: Sectores altamente regulados

Optimizador de Acceso Condicional (Entra)

1.                      Detecta brechas en políticas de acceso en tiempo real

2.                      Sugiere correcciones con un clic

3.                      Clave para: Empresas con teletrabajo

Agente de Corrección de Vulnerabilidades (Intune)

1.                      Identifica y prioriza vulnerabilidades en sistemas Windows

2.                      Automatiza la aplicación de parches críticos con aprobación admin

3.                      Reduce superficie de ataque en un 40% en promedio

4.                      Ideal para: Empresas con flotas de dispositivos dispersas

Agente de Inteligencia sobre Amenazas (Security Copilot)

1.                      Analiza 84 billones de señales diarias para riesgos específicos

2.                      Genera reportes personalizados por industria y región

3.                      Actualización en tiempo real de TTPs de atacantes

4.                      Perfecto para: Equipos SOC con recursos limitados

Investigador de Seguridad de Datos (Purview)

1.                      Detecta 15 tipos de datos confidenciales expuestos

2.                      Automatiza flujos de remediación para incidentes

3.                      Integración con casos de Defender y Purview

4.                      Clave para: Cumplimiento RGPD/HIPAA/SOX

Los 5 agentes desarrollados por socios estratégicos

Beneficios Tangibles para Consultores:

Reducción de Costos Operativos:

1.                      Los clientes pueden ahorrar hasta 240 horas/mes en gestión manual

2.                      Ejemplo: El agente de phishing procesa 1,000 alertas en 5 minutos vs 8 horas humana

Nuevos Modelos de Servicio:

1.                      Consultoría de implementación (3-5 días por agente)

2.                      Monitoreo gestionado de agentes (MRR recurrente)

3.                      Auditorías trimestrales de eficiencia

Diferenciación Competitiva:

1.                      Certificaciones exclusivas de Microsoft

2.                      Acceso anticipado a betas

3.                      Co-marketing con socios tecnológicos

Oportunidades para consultores tecnológicos

Servicios de implementación

• Auditorías de preparación para IA

• Configuración personalizada por industria

• Capacitación para equipos de seguridad

Paquetización inteligente

• Paquete Esencial: Agentes contra phishing + protección de datos

• Paquete Enterprise: Todos los agentes + monitoreo continuo

Verticalización por sector

• Salud: Enfocado en cumplimiento HIPAA

• Financiero: Protección contra fraude

• Retail: Defensa de datos de clientes

Leer el artículo en Cloud Legion

A medida que las empresas integran cada vez más Microsoft Copilot en sus flujos de trabajo diarios, los ciberdelincuentes han desarrollado sofisticadas campañas de phishing dirigidas específicamente a los usuarios de este asistente impulsado por IA .

La adopción generalizada de Copilot ha creado una nueva superficie de ataque que los ciberdelincuentes están explotando activamente.

Según la última investigación de Cofense, los atacantes están distribuyendo correos electrónicos de phishing cuidadosamente elaborados que parecen originarse en Copilot, imitando comunicaciones legítimas de Microsoft.

“ Con nuevos servicios como este, los empleados pueden no ser conscientes de qué tipos de correos electrónicos deberían recibir del proveedor ”, dice el informe de Cofense. “ Es posible que no estén acostumbrados al formato o la apariencia de estos mensajes, por lo que es fácil imaginar un escenario en el que un empleado, que utiliza este servicio por primera vez, recibe una factura falsa y termina haciendo clic en un enlace fraudulento ”.

Cuando los destinatarios hacen clic en los enlaces incluidos en estos correos electrónicos de phishing, son redirigidos a réplicas convincentes de las páginas de bienvenida de Microsoft Copilot. Estas páginas falsas se parecen mucho a las interfaces legítimas de Microsoft, replicando con precisión elementos de marca y esquemas de diseño.

Sin embargo, las URL no pertenecen a dominios de Microsoft, sino a sitios web fraudulentos. El esquema continúa con un mensaje de inicio de sesión, que imita el proceso de autenticación de Microsoft.

Los analistas de seguridad advierten que la parte más preocupante del ataque ocurre en la fase final, cuando las víctimas, después de ingresar sus credenciales, se enfrentan a una página falsa de autenticación multifactor (MFA) de Microsoft Authenticator. En este punto, el empleado puede estar esperando una solicitud de MFA legítima, lo que inadvertidamente le da al atacante la oportunidad de acceder a la cuenta, cambiar contraseñas o realizar otras acciones maliciosas.

Leer el artículo en Cloud Legion

La inteligencia artificial (IA) se ha consolidado como una herramienta esencial para las empresas que buscan aumentar la eficiencia y reducir los riesgos operativos. Entre las diversas aplicaciones de la IA, una de las más prometedoras es su capacidad para prevenir fallos del sistema. Esta funcionalidad es particularmente relevante en un escenario donde la interrupción del servicio puede significar pérdidas financieras y daños a la reputación.

En este artículo, explicaremos cómo funciona la IA para identificar fallas, anticipar problemas y garantizar la continuidad del sistema.

¿Qué son las fallas del sistema y sus impactos?

Las fallas del sistema ocurren cuando hay interrupciones o anomalías en el funcionamiento del software, hardware o redes. Pueden ser causados por factores como errores humanos, como configuraciones incorrectas, problemas de hardware, como sobrecalentamiento o fallos de componentes, errores de software, generados durante el desarrollo o actualización, o incluso ataques cibernéticos que comprometan la integridad o seguridad del sistema.

Las consecuencias varían según la gravedad y criticidad del sistema afectado, y pueden incluir pérdida de datos, indisponibilidad del servicio, multas por incumplimiento e insatisfacción del cliente.

Frente a estos riesgos, la IA aparece como un aliado para prevenir los problemas antes de que ocurran.

Cómo funciona la inteligencia artificial para prevenir fallos

La prevención de fallas mediante IA implica una combinación de algoritmos avanzados, análisis de datos en tiempo real y aprendizaje automático. A continuación se muestran algunas formas en las que la IA desempeña este papel:

1. Monitoreo proactivo La IA monitorea continuamente el rendimiento de los sistemas, identificando anomalías antes de que se conviertan en problemas graves. Esto se hace mediante la recopilación de datos en tiempo real y el análisis de la memoria y el tráfico de la red. También compara patrones operativos actuales e históricos para identificar desviaciones.
   
   
2. Análisis predictivo Una de las mayores ventajas de la IA es su capacidad de predecir fallos futuros basándose en datos pasados. Para ello, se pueden utilizar algoritmos de aprendizaje automático, que analizan patrones recurrentes y correlacionan variables que indican posibles fallos. El análisis predictivo ayuda a los equipos de TI a realizar mantenimiento preventivo, reduciendo el tiempo de inactividad.
   
   
3. Automatización de respuestas La IA no solo detecta problemas, sino que también puede responder automáticamente a ellos reiniciando sistemas, ajustando configuraciones y emitiendo alertas a los equipos responsables antes de que los usuarios sientan el impacto.
   
   
4. Detección de amenazas cibernéticas Muchos fallos del sistema son causados por ataques cibernéticos. La IA puede identificar actividades maliciosas como intentos de piratería, acceso no autorizado y movimientos de datos anómalos. También puede escanear en busca de agujeros de seguridad importantes.
   
   

Ventajas del uso de IA en la prevención de fallos

La adopción de soluciones basadas en IA para prevenir fallas trae varios beneficios, incluida la reducción de costos. Vea algunos de ellos:

• Reducción de costes: evitar fallos significa evitar gastos en reparaciones de emergencia, multas por tiempos de inactividad y daños a la reputación.
• Mayor disponibilidad: los sistemas monitoreados por IA tienen menos tiempos de inactividad, lo que garantiza una mayor continuidad operativa.
• Mayor eficiencia: al automatizar las respuestas, los equipos de TI pueden centrarse en actividades más estratégicas.
• Experiencia del cliente mejorada: la estabilidad del sistema se traduce en menos interrupciones y una mayor satisfacción del usuario.

Ejemplos prácticos del uso de IA en la prevención de fallos

Empresas de diferentes sectores ya utilizan IA para garantizar el funcionamiento continuo de sus sistemas. Algunos ejemplos incluyen:

• Servicios financieros: las instituciones bancarias utilizan IA para monitorear transacciones en tiempo real, identificando inconsistencias que puedan indicar fallas o fraudes.
• Fabricación: Las industrias utilizan sensores conectados a sistemas de IA para predecir fallas de las máquinas y evitar interrupciones en la línea de producción. Los problemas de energía pueden, por ejemplo, activar los generadores automáticamente.
• Atención médica: los hospitales emplean IA para monitorear equipos críticos como ventiladores y monitores cardíacos, garantizando que siempre funcionen correctamente.

Cómo empezar a implementar la IA en la prevención de fallos

Si su empresa desea adoptar IA para prevenir fallos, siga estos pasos:

1. Identificar sistemas críticos Determine qué sistemas o procesos tienen el mayor impacto en sus operaciones y por lo tanto requieren un monitoreo constante.
   
   
2. Invierta en infraestructura adecuada Asegúrese de que su infraestructura de TI esté preparada para soportar herramientas de IA, incluida la capacidad de almacenamiento y procesamiento de datos.
   
   
3. Elija la solución de IA adecuada Existen varias herramientas en el mercado destinadas a prevenir fallos. Evalúa tus necesidades específicas y elige la que más te convenga.
   
   
4. Capacita a tu equipo Adoptar IA requiere un equipo preparado para gestionar e interpretar los datos generados. Invierta en capacitación para sus empleados.
   
   
5. Monitorear y optimizar constantemente Incluso con IA, siempre es importante revisar periódicamente los resultados y ajustar los parámetros para asegurar la efectividad de las soluciones implementadas.
   
   

El futuro de la IA en la prevención de fallos

A medida que la tecnología continúa avanzando, se espera que las soluciones de IA para la prevención de fallas se vuelvan aún más sofisticadas. Algunas tendencias incluyen el uso de IA generativa para realizar pronósticos más precisos, a través de modelos que pueden simular escenarios complejos para anticipar fallas. 

La integración con IoT (Internet of Things) también es tendencia , como sensores conectados a sistemas de IA que permitirán monitorizar en tiempo real los equipos físicos. Y, por último, la automatización total: las respuestas a los fallos serán cada vez más automatizadas, lo que minimizará la necesidad de intervención humana.

Cómo la inteligencia artificial previene fallos del sistema

La inteligencia artificial está cambiando la forma en que las empresas abordan los fallos del sistema. Al integrar IA en sus operaciones, las organizaciones pueden garantizar una mayor estabilidad, reducir costos y ofrecer experiencias de cliente más significativas.

Las ventajas competitivas de adoptar IA son claras y su impacto positivo se puede sentir en todos los niveles de operaciones, incluidas las finanzas. Es un camino sin retorno que tiende a utilizarse aún más en los próximos años.

Leer el artículo en Cloud Legion