La paradoja de la IA de Microsoft: el comprador empresarial podría estar pagando dos veces

Google News ha puesto sobre la mesa un incómodo argumento de Microsoft: las empresas que compran IA corren el riesgo de volver a pagar con el conocimiento que las hace competitivas. El CEO de Microsoft, Satya Nadella, llama a este conflicto la paradoja inversa de la información. Su planteamiento invierte la historia habitual sobre el valor de la IA. Los mejores resultados requieren un contexto más rico, pero ese contexto puede contener años de decisiones, correcciones y criterio propietario.

La advertencia importa porque la IA empresarial ha superado los prompts aislados. Los agentes ahora recuperan documentos, llaman herramientas, observan resultados y registran comentarios a lo largo de flujos de trabajo completos. Cada interacción puede revelar cómo una empresa define la calidad, gestiona excepciones y toma decisiones. El proveedor del modelo aporta la inteligencia, pero el cliente aporta el conocimiento operativo que la hace útil.

Eso no significa que cada prompt empresarial se convierta en datos de entrenamiento. Microsoft, OpenAI, Google y Anthropic publican protecciones que restringen el entrenamiento con contenido de clientes comerciales. La pregunta más profunda es quién controla el ciclo de aprendizaje circundante, incluidas las evaluaciones, los rastros de flujo de trabajo, los modelos adaptados y los comentarios acumulados.

Google News convirtió una advertencia de Microsoft en una historia sobre IA empresarial

El acontecimiento importante no es el lanzamiento de un nuevo modelo. Es el reconocimiento público de Microsoft de que la adopción de IA puede transferir conocimiento estratégico en la dirección equivocada.

Nadella presentó la paradoja inversa de la información en un ensayo del 12 de julio. Adaptó un antiguo problema económico asociado con Kenneth Arrow. En la versión de Arrow, un vendedor debe revelar información antes de que un comprador pueda juzgar su valor, con el riesgo de regalar el producto.

Nadella sostiene que la IA invierte la dirección. Una empresa ya ha pagado por acceder a un modelo, pero el modelo necesita información específica de la empresa antes de poder ofrecer valor específico para ella. Por tanto, el comprador revela conocimiento después de adquirir el producto.

Ese conocimiento incluye más que documentos confidenciales. Puede abarcar prompts desarrollados mediante experimentación repetida, correcciones aportadas por especialistas, criterios internos de evaluación y rastros que muestran cómo los empleados completan trabajos difíciles.

“Cada corrección se destila en conocimiento institucional”, escribió Nadella en su ensayo original. La afirmación identifica la tensión central del artículo. Los sistemas de IA se vuelven útiles al observar precisamente el comportamiento que las empresas deberían tener cuidado de no ceder.

El asunto llegó a una audiencia más amplia a través de cobertura difundida por Google News, incluido el inicial análisis de seguridad. Esa distribución importa porque es fácil confundir el argumento con otra advertencia sobre empleados que pegan secretos en chatbots.

La preocupación de Nadella es más amplia. Incluso un sistema aprobado que opera bajo un acuerdo comercial puede crear un problema de propiedad en torno al conocimiento derivado. El documento original podría seguir protegido, mientras que un conjunto de evaluación, un rastro de agente o un flujo de trabajo optimizado captura su significado operativo.

Pensemos en una aseguradora que utiliza un agente de IA para revisar reclamaciones inusuales. Los archivos fuente contienen información sensible, pero el activo más valioso puede ser la secuencia de comprobaciones realizada por investigadores experimentados. Sus correcciones enseñan al sistema qué incoherencias importan y qué excepciones son legítimas.

Un fabricante se enfrenta al mismo problema cuando los ingenieros usan un asistente para diagnosticar fallos de equipos. El manual es importante, pero el conocimiento escaso reside en cómo los ingenieros sénior combinan lecturas de sensores, historial de mantenimiento y síntomas sutiles. Los comentarios repetidos pueden convertir ese criterio en una maquinaria reutilizable.

Esta distinción separa la protección de datos del control del conocimiento. Los equipos de seguridad preguntan tradicionalmente quién puede acceder a un archivo, cuánto tiempo se conserva y si está cifrado. La gobernanza de datos de IA empresarial también debe preguntar quién se beneficia del aprendizaje producido cuando los empleados usan ese archivo.

El concepto recibió un tratamiento más formal poco después. Un artículo de investigación de seis páginas publicado el 14 de julio modela lo que sus autores denominan el equivalente, del lado del usuario, al problema de Arrow. Su modelo económico sostiene que la retención puede superar o quedar por debajo del nivel socialmente deseable, según cómo las plataformas capturen beneficios e internalicen los daños.

Esa salvedad es importante. La retención no es automáticamente perjudicial. El aprendizaje compartido puede mejorar la seguridad, la fiabilidad y el rendimiento de los modelos. El conflicto surge cuando el proveedor captura esos beneficios mientras el cliente asume una pérdida de control poco clara.

La presión recae sobre los compradores, no solo sobre los proveedores de IA

Los compradores empresariales ahora deben evaluar la IA como una relación de conocimiento, no simplemente como una compra de software.

La presión inmediata recae sobre los directores de sistemas de información, líderes de seguridad, equipos de compras y responsables de negocio que despliegan agentes. Deben decidir qué información puede procesar un sistema y qué artefactos de aprendizaje debe conservar la empresa.

Los contratos de software tradicionales se centran en la disponibilidad del servicio, los controles de acceso, el soporte, la confidencialidad y la eliminación. Estas cuestiones siguen siendo necesarias. No cubren por completo un sistema de IA que observa correcciones de usuarios y cambia su comportamiento mediante recuperación, memoria, ajuste u orquestación.

Una capa de orquestación es el software que selecciona modelos, reúne contexto, llama herramientas y gestiona el estado del flujo de trabajo. Si un proveedor controla esa capa, puede convertirse en el único lugar donde el conocimiento operativo de IA acumulado de una empresa funciona de forma fiable.

Eso crea presión incluso cuando el modelo subyacente nunca se entrena con prompts de clientes. Una empresa puede seguir dependiendo de un formato de memoria específico del proveedor, un servicio de evaluación, un marco de agentes o un sistema de conectores. Cambiar de modelo implica entonces reconstruir a su alrededor el flujo de trabajo aprendido.

Las evaluaciones, habitualmente abreviadas como evals, ilustran el problema. Una eval es una prueba estructurada que se utiliza para determinar si un sistema de IA cumple un estándar definido. Las evals de un banco podrían codificar qué se considera una investigación de fraude aceptable, una explicación conforme o una decisión de escalamiento.

Esas pruebas pueden ser más valiosas que el modelo. Los competidores pueden licenciar modelos fundacionales similares, pero no pueden reproducir fácilmente las definiciones, ejemplos, casos límite y umbrales de fallo del banco. Las evals representan experiencia institucional comprimida.

La misma lógica se aplica a las correcciones. Un abogado que revisa un análisis contractual generado por IA revela qué cláusulas merecen atención y qué riesgos acepta la organización. Un responsable de soporte que anula a un agente revela la diferencia entre una respuesta técnicamente correcta y una que preserva la relación con un cliente.

Por eso los datos de IA empresarial incluyen información conductual además de contenido almacenado. Un prompt describe la tarea actual. La corrección explica cuál cree la organización que debería haber sido la tarea correcta.

Los líderes empresariales también se enfrentan a un problema de medición. Los paneles de productividad suelen contar resúmenes producidos, tickets cerrados o código aceptado. Rara vez miden si la experiencia reutilizable se acumuló dentro de la empresa o en un servicio controlado por un proveedor.

Por tanto, una implementación puede mostrar ganancias inmediatas mientras debilita el control a largo plazo. Los empleados completan las tareas más rápido, pero la organización no obtiene un registro portátil de por qué mejoró el agente. La experiencia permanece dispersa entre historiales de chat, registros propietarios o telemetría de servicio inaccesible.

Los trabajadores del conocimiento sienten esta presión a menor escala. Sus mejores prompts y patrones de revisión se convierten en parte del trabajo diario, pero muchos no pueden exportarlos como activos estructurados. Si cambian de herramientas, el aprendizaje acumulado suele desaparecer.

Un enfoque controlado de combinación de conocimiento puede reducir esa fragmentación al mantener el contexto fuente conectado a una capa de conocimiento gestionada por el usuario. El principio estratégico es más amplio que cualquier producto: el contexto importante debe seguir siendo utilizable entre modelos y flujos de trabajo.

En consecuencia, los equipos de compras deben mirar más allá de una simple promesa sobre datos de entrenamiento. Necesitan respuestas claras sobre retención, uso secundario, revisión humana, subprocesadores, propiedad de las salidas, manejo de comentarios, eliminación, portabilidad y acceso de auditoría.

También deben distinguir entre ediciones de producto. Los servicios para consumidores, empresas, API y entornos empresariales suelen operar bajo condiciones diferentes. Una protección disponible en un espacio de trabajo corporativo gestionado puede no aplicarse cuando un empleado inicia sesión en una cuenta personal.

Esa distinción hace que la IA en la sombra sea especialmente arriesgada. La IA en la sombra describe herramientas utilizadas sin aprobación ni visibilidad organizacional. Un empleado puede cargar contexto valioso a un servicio para consumidores porque el sistema aprobado parece más lento o menos capaz.

La empresa entonces carece tanto de un límite técnico como de uno contractual. Puede que no sepa qué cuenta se utilizó, si el historial estaba activado, cómo se conservó el contenido o dónde entró la salida en un proceso de negocio.

La respuesta obligada no es una prohibición general. Prohibir herramientas útiles suele empujar la actividad aún más fuera de los sistemas gestionados. La respuesta más duradera consiste en ofrecer a los empleados opciones aprobadas, al tiempo que se hace visible y aplicable el límite del conocimiento.

La verdadera disyuntiva es mejor contexto frente a control

La paradoja inversa de la información existe porque el sistema de IA más seguro suele estar menos informado, mientras que el sistema más informado puede volverse más difícil de gobernar.

Un modelo genérico puede redactar texto rutinario sin información sensible. No puede explicar de forma fiable una excepción interna, evaluar un diseño privado o actuar dentro de un proceso específico de una empresa sin contexto adicional.

La generación aumentada por recuperación, comúnmente llamada RAG, proporciona ese contexto al encontrar registros relevantes e insertarlos en una solicitud al modelo. Los agentes van más allá al utilizar herramientas, leer estados y realizar acciones en varios pasos.

Cada capacidad incrementa el valor potencial. También amplía la ruta por la que se desplazan los datos de IA empresarial. Una solicitud puede pasar por una aplicación, un servicio de recuperación, un endpoint de modelo, una plataforma de registro, herramientas conectadas y sistemas de monitorización.

Por tanto, el límite de seguridad relevante se extiende más allá del proveedor del modelo. Una empresa debe considerar cada componente que recibe prompts, pasajes recuperados, artefactos de razonamiento intermedios, resultados de herramientas o comentarios de usuarios.

Esta es una razón por la que un compromiso de “no utilizado para entrenamiento” no resuelve el asunto. El entrenamiento es una forma de uso. La retención para supervisión de abuso, el almacenamiento para el historial de conversaciones, la revisión administrativa y el procesamiento por servicios conectados siguen siendo cuestiones independientes.

Microsoft afirma que los prompts, las respuestas y los datos a los que se accede mediante Microsoft Graph no se utilizan para entrenar los modelos fundacionales que sustentan Microsoft 365 Copilot. Sus protecciones empresariales también sitúan el uso organizacional bajo las salvaguardas comerciales de datos existentes.

OpenAI también afirma que, de forma predeterminada, no entrena con datos procedentes de sus productos empresariales ni de su plataforma API. Su documentación sobre privacidad empresarial indica que las organizaciones que cumplan los requisitos pueden configurar la retención, incluida la retención cero de datos para usos elegibles de la API.

Google afirma que el contenido utilizado por Gemini dentro de Workspace no se usa para entrenar ni mejorar los modelos generativos subyacentes fuera de Workspace sin autorización. Sus controles de Workspace también distinguen el uso empresarial administrado de los servicios personales y las funciones opcionales de intercambio de datos.

Anthropic afirma que los datos conservados a través de su API comercial no se utilizan para el entrenamiento de modelos sin consentimiento expreso. También documenta acuerdos de retención cero de datos para productos elegibles, aunque la disponibilidad depende del servicio y del contrato.

Estos compromisos cuestionan directamente la versión más contundente de la advertencia de Nadella. Si los proveedores empresariales no entrenan con contenido de los clientes, es inexacto insinuar que cada prompt mejora automáticamente un modelo fundacional compartido.

La paradoja persiste de una forma más acotada y defendible. El cliente aún puede perder el control práctico sobre el sistema de aprendizaje construido alrededor del modelo, incluso cuando su contenido en bruto queda excluido del entrenamiento general.

Imaginemos una empresa de software que despliega un agente de programación. El proveedor no entrena un modelo fundacional con el repositorio de la empresa. Sin embargo, el valor del agente depende de instrucciones propietarias, suites de pruebas, comentarios de revisión, integraciones de herramientas y un historial cada vez mayor de cambios aceptados.

Si esos activos existen únicamente dentro del entorno del proveedor, la empresa sigue expuesta al bloqueo por dependencia. Es propietaria del código, pero no necesariamente del proceso completo que hizo eficaz al agente.

La portabilidad de modelos ayuda, pero no resuelve esto por sí sola. Dos modelos pueden interpretar el mismo prompt de forma diferente. Las llamadas a herramientas, la memoria, los filtros de seguridad, los límites de contexto y los formatos de salida también varían. Migrar un agente exige preservar su comportamiento, no simplemente cambiar un endpoint de API.

Por ello, las empresas necesitan evaluaciones portables. Deberían poder ejecutar las mismas pruebas de negocio frente a varios modelos y comparar los resultados según sus propios criterios. Esto convierte la elección de modelo en una decisión operativa, en lugar de una dependencia irreversible.

También necesitan retroalimentación controlada. Un botón de pulgar hacia abajo puede ayudar a un proveedor a mejorar un producto, pero una corrección interna puede tener valor estratégico. Las organizaciones deberían decidir qué comentarios salen de su perímetro y cuáles pasan a formar parte de un historial de aprendizaje privado.

Los sistemas locales de conocimiento ofrecen otra capa de control. Mantener el material fuente, las anotaciones y los índices de recuperación bajo gobernanza organizacional puede limitar divulgaciones innecesarias. También hace más práctica la sustitución de modelos, porque la capa de conocimiento no desaparece con la interfaz.

Una base de conocimientos técnicos con capacidad de búsqueda puede conservar la procedencia junto al contexto recuperado. Esto importa cuando los ingenieros deben verificar por qué apareció una respuesta y qué documento la respaldaba.

Ninguna de estas medidas elimina la disyuntiva. Una empresa que retiene demasiado contexto obtiene respuestas genéricas y automatización débil. Una empresa que comparte todo gana rendimiento, pero aumenta su exposición, dependencia y trabajo de gobernanza.

El límite correcto variará según el flujo de trabajo. Redactar texto de marketing público presenta un riesgo distinto al de revisar documentos de una fusión. Resumir una política aprobada difiere de permitir que un agente modifique infraestructura de producción.

La tarea estratégica consiste en ajustar la divulgación al valor y la reversibilidad de la acción. Los flujos de trabajo propietarios de alto valor requieren mayor aislamiento, registros más claros, portabilidad más sólida y aprobaciones más deliberadas que las tareas administrativas de bajo riesgo.

El argumento de Microsoft también se aplica a Microsoft

La advertencia de Nadella es creíble precisamente porque Microsoft no puede situarse fuera del conflicto que describe.

Microsoft vende modelos, copilotos, infraestructura en la nube, herramientas para el desarrollo de agentes, plataformas de datos y servicios de seguridad. Se beneficia cuando los clientes llevan más trabajo y contexto a sus sistemas.

Esa posición no invalida la paradoja inversa de la información. Sí convierte a Microsoft en parte del mapa de adversarios. La tensión no enfrenta a Microsoft con otra empresa de IA. Enfrenta la promesa del proveedor de una inteligencia útil con la necesidad del comprador de preservar conocimiento independiente.

Las protecciones empresariales de Microsoft abordan partes importantes de esta preocupación. Restringen el entrenamiento de modelos fundacionales con prompts organizacionales y conectan Copilot con los controles existentes de identidad, cumplimiento y datos.

Aun así, una empresa puede seguir esas protecciones y mantener su dependencia del entorno de Microsoft. Sus agentes pueden depender de permisos de Microsoft Graph, flujos de Copilot Studio, políticas de Purview, conectores propietarios o herramientas de evaluación específicas del proveedor.

OpenAI, Google y Anthropic enfrentan un escrutinio equivalente. Todas quieren que los clientes empresariales conecten fuentes más profundas, desplieguen agentes más capaces y amplíen la cobertura de sus flujos de trabajo. Esos objetivos exigen que los clientes confíen en una superficie técnica cada vez mayor.

La competencia genera presión útil. Los proveedores ahora anuncian exclusiones de entrenamiento, controles administrativos, cifrado, opciones de retención y funciones de cumplimiento. Los compradores pueden comparar esas promesas y negociar condiciones más sólidas.

Sin embargo, la documentación de producto no puede sustituir la verificación a nivel de sistema. Un proveedor puede proteger su propio endpoint mientras un conector de terceros almacena prompts. Una herramienta interna de registro puede capturar respuestas completas. Una capa de recuperación mal configurada puede exponer registros entre departamentos.

La IA agéntica eleva el riesgo porque las acciones generan nuevos datos. Un agente que revisa un documento produce un resumen. Un agente que completa un flujo de trabajo produce una secuencia de decisiones, llamadas a herramientas, fallos, reintentos y aprobaciones.

Esa secuencia puede revelar más que el documento original. Muestra cómo la organización transforma información en acción. Para los competidores, ese conocimiento sobre procesos puede ser más difícil de obtener que los datos subyacentes.

Los riesgos de seguridad también van más allá del uso por parte del proveedor. La inyección de prompts ocurre cuando instrucciones maliciosas entran en un sistema de IA mediante la entrada del usuario o contenido recuperado. Esas instrucciones pueden intentar redirigir a un agente, revelar contexto confidencial o usar indebidamente herramientas conectadas.

El perfil de IA de NIST identifica la inyección de prompts, la privacidad, la seguridad y la gobernanza de datos entre los riesgos que las organizaciones deberían gestionar. Esto refuerza un punto clave: los límites contractuales de entrenamiento no impiden que un atacante explote un sistema excesivamente conectado.

La lectura escéptica del ensayo de Nadella tiene, por tanto, dos partes. Primero, los servicios empresariales ya ofrecen protecciones que complican la idea de un aprendizaje unidireccional. Segundo, Microsoft tiene un interés comercial en presentar la infraestructura empresarial privada como la solución.

La dirección que propone se alinea con la cartera de Microsoft. Las empresas que quieren límites de datos controlados, evaluación privada, modelos adaptables y agentes gobernados pueden adquirir más servicios de nube y seguridad. Tanto el diagnóstico como los intereses comerciales de Microsoft pueden ser reales.

Existe otra incertidumbre. No todo rastro o corrección produce inteligencia competitiva significativa. Muchos prompts son repetitivos, de baja calidad o específicos de una tarea. Tratar todos los datos de interacción como un tesoro corporativo puede generar controles costosos sin un beneficio proporcional.

Las organizaciones necesitan clasificación, no mitología. La corrección de un responsable de cumplimiento sobre una decisión regulada puede ser muy valiosa. Una solicitud para reformatear notas de reunión probablemente no lo sea.

Los equipos deberían identificar dónde entra realmente el juicio propietario en el sistema. Después pueden proteger las evaluaciones, ejemplos, rastros y decisiones vinculados a esos flujos de trabajo sin poner cada interacción de IA tras la misma barrera.

También deberían probar la portabilidad entre proveedores antes de comprometerse a gran escala. Una afirmación de neutralidad de modelo significa poco si una empresa no puede reproducir el comportamiento en otro lugar. Los compradores necesitan pruebas de que los prompts, las herramientas, la memoria, las evaluaciones y los registros pueden moverse juntos.

La respuesta más sólida no es el autoalojamiento completo para cada carga de trabajo. Ejecutar modelos internamente introduce cargas de infraestructura, seguridad, personal y gestión de modelos. También puede dejar a los equipos con capacidades más débiles o actualizaciones más lentas.

Una arquitectura mixta es más plausible. Las tareas comunes pueden usar servicios gestionados con protecciones contractuales. Los flujos de trabajo sensibles pueden usar entornos aislados, recuperación más limitada, evaluación privada y retención más estricta.

El equilibrio debería seguir abierto a revisión. A medida que los modelos mejoran, una menor cantidad de contexto puede lograr el mismo resultado. A medida que los agentes obtienen más acceso, las consecuencias de una interacción comprometida pueden aumentar.

Qué deberían observar los lectores de Google News a continuación

La próxima fase se decidirá por evaluaciones portables, controles de retención exigibles y pruebas de que el aprendizaje empresarial permanece con el comprador.

La primera señal es si los principales proveedores de IA convierten la portabilidad de evaluaciones en una función empresarial estándar. Los clientes deberían poder exportar casos de prueba, reglas de puntuación, registros de fallos y correcciones humanas en formatos documentados.

Si eso ocurre, el diagnóstico de Nadella gana respaldo mientras se debilita el riesgo de bloqueo. Los proveedores reconocerían que la capa de aprendizaje pertenece a los clientes y competirían por el rendimiento de los modelos, en lugar de por una infraestructura de evaluación cautiva.

Si las evaluaciones siguen siendo difíciles de exportar, la paradoja se vuelve más concreta. El cliente puede ser propietario de sus documentos, pero carecer de una forma práctica de trasladar los estándares que definen un comportamiento aceptable de la IA.

La segunda señal es la expansión de controles de retención verificables. El lenguaje contractual importa, pero los compradores también necesitan ajustes administrativos, registros, pruebas de eliminación, opciones de procesamiento regional y límites claros para la supervisión de abusos.

La retención cero de datos merece especial atención, aunque la etiqueta requiere una lectura cuidadosa. Puede aplicarse al tráfico elegible de la API y excluir interfaces de producto, registros relacionados con la seguridad o servicios conectados.

Si los proveedores amplían estos controles a agentes y aplicaciones del lugar de trabajo, se debilitará el temor más fuerte sobre la transferencia ascendente de información. Si las excepciones se multiplican a medida que los agentes ganan capacidades, los responsables de seguridad necesitarán patrones de implementación más aislados.

La tercera señal es si las empresas reportan valor de IA a través de activos de conocimiento reutilizables. Las estadísticas de productividad por sí solas no mostrarán quién controla el aprendizaje. Las empresas deberían medir la cobertura de evaluaciones portables, las correcciones documentadas, el tiempo de cambio de modelo y la proporción de flujos de trabajo de alto riesgo que operan dentro de límites aprobados.

La mejora en esas métricas respaldaría el modelo de aprendizaje controlado por el comprador que describe Nadella. La dependencia continua de paneles de control de proveedores e historiales opacos sugeriría que la inteligencia se está acumulando fuera del control efectivo del cliente.

Es probable que Google News siga destacando la disputa porque conecta varias preocupaciones activas: seguridad de la IA, privacidad, propiedad intelectual, concentración de proveedores y gobernanza de agentes. Los lectores deberían evitar reducirla a la afirmación de que cada modelo comercial se entrena con cada prompt.

La pregunta más útil es más acotada: después de que un sistema de IA complete un año de trabajo específico de una empresa, ¿qué inteligencia reutilizable posee la compañía que antes no tenía?

Los compradores empresariales deberían poder responder con algo más que transcripciones de chats guardadas. Deberían contar con evaluaciones portables, contexto gobernado, flujos de trabajo documentados, correcciones rastreables y la opción de cambiar de modelo sin descartar la experiencia acumulada.

Los desarrolladores deberían preguntar dónde se almacenan los prompts, los resultados de las herramientas y los rastros de los agentes. Los equipos de seguridad deberían identificar cada procesador dentro del flujo de trabajo. Los trabajadores del conocimiento deberían saber qué cuenta y qué política cubren la información que proporcionan.

La paradoja inversa de la información no demuestra que no se pueda confiar en la IA alojada. Advierte que las promesas de privacidad solo abordan una parte del intercambio. Un prompt protegido puede seguir formando parte de un sistema cuyo aprendizaje útil continúa siendo difícil de poseer o trasladar.

A medida que la futura cobertura de Google News siga las políticas de los proveedores y los despliegues empresariales, busque indicios de una portabilidad real. ¿Pueden los clientes exportar lo que aprendieron sus agentes, volver a ejecutar sus pruebas en otro lugar y preservar el contexto detrás de decisiones importantes?

Si la respuesta pasa a ser afirmativa, la IA empresarial podrá ofrecer inteligencia externa sin absorber la identidad del cliente. Si la respuesta sigue sin estar clara, el segundo pago no aparecerá en una factura. Aparecerá cuando la empresa intente irse.