Un agente sin persistencia entre sesiones comienza cada sesión desde el contexto que se le proporciona. La persistencia puede reducir la necesidad de repetir el mismo contexto en cada sesión, pero también crea obligaciones de privacidad, precisión, aislamiento y eliminación.
Este es el problema de la memoria. Las ventanas de contexto gestionan la conversación actual. La memoria a largo plazo —entre sesiones, entre días, entre meses— necesita su propia arquitectura. Y es más difícil de lo que parece.
Este artículo presenta un diseño de referencia para probar, no una implementación certificada. Los equipos de producto deben verificar los controles de acceso, la corrección, la conservación, la eliminación, la restauración y la calidad de la recuperación en su propio stack.
Qué significa «memoria»
Una visión simplista: memoria = «el modelo recuerda cosas entre conversaciones». La realidad es más matizada. La ciencia cognitiva distingue tipos de memoria, y la memoria de los agentes de IA se beneficia de una distinción similar:
Memoria de trabajo. La conversación actual. Se mantiene en la ventana de contexto. Se pierde cuando termina la conversación (a menos que se persista).
Memoria episódica. Eventos pasados específicos. «El martes pasado discutimos X.» «Hace tres meses decidiste Y.»
Memoria semántica. Hechos generales. «Tu nombre es Alice.» «Prefieres respuestas concisas.» «Tu empresa está en Tallin.»
Memoria procedimental. Cómo hacer las cosas. «Cuando el usuario pide una reunión, usa esta plantilla.» «Cuando el cliente esté en la categoría X, sigue el proceso Y.»
Diferentes tipos de memoria sirven a funciones diferentes. Usa solo las capas que el producto pueda justificar y operar; almacenar más no es automáticamente mejor.
Qué debe lograr la memoria
Antes de la arquitectura, los objetivos:
Continuidad. El agente retoma donde lo dejó. Sin tener que presentarte de nuevo en cada sesión.
Personalización. El agente aplica tus preferencias sin que se te pida. Escribe con tu estilo, usa tus herramientas y hace referencia a tu equipo.
Preservación del contexto. Las decisiones de conversaciones pasadas informan las actuales. «Decidimos X el mes pasado» debe recordarse.
Reutilización confirmada de preferencias. El sistema puede reaplicar una preferencia explícita o verificada en los alcances donde es válida. La repetición por sí sola no prueba que una herramienta, idioma o comportamiento deba convertirse en un valor predeterminado.
Privacidad y olvido. Qué se recuerda, qué no, qué se elimina. Tanto para la confianza del usuario como para el cumplimiento legal.
Estos objetivos pueden entrar en conflicto. La continuidad puede beneficiarse de cierta persistencia, mientras que la privacidad y la precisión favorecen la minimización, los límites de propósito, la corrección y la eliminación. La arquitectura debe hacer explícitas esas compensaciones.
La arquitectura
Una arquitectura en capas típica:
┌─────────────────────────────────────┐
│ Memoria de trabajo (en contexto) │ Conversación actual
├─────────────────────────────────────┤
│ Memoria de sesión (reciente) │ Últimas N conversaciones
├─────────────────────────────────────┤
│ Memoria episódica (a largo plazo) │ Eventos pasados específicos
├─────────────────────────────────────┤
│ Memoria semántica (hechos) │ Hechos estables del usuario
├─────────────────────────────────────┤
│ Memoria procedimental (preferencias)│ Cómo comportarse para este usuario
└─────────────────────────────────────┘
Cada capa necesita comportamiento explícito de almacenamiento, recuperación, acceso, procedencia, corrección, conservación y eliminación; múltiples capas lógicas pueden compartir un almacén físico.
Revisaremos cada una.
Capa 1: Memoria de trabajo
Ya cubierta en Ingeniería del contexto. La conversación actual en el contexto. Para conversaciones de varios turnos, contexto escalonado con los turnos recientes literales y los anteriores resumidos.
Una transferencia a la memoria a largo plazo puede ocurrir en un punto de control explícito, un evento duradero o al final de la sesión. Dado que las sesiones pueden terminar abruptamente, persiste solo los candidatos aprobados y haz observable el estado de escritura en lugar de asumir que siempre se ejecuta un hook de fin de sesión.
Capa 2: Memoria de sesión
Los resúmenes de sesiones recientes pueden guardarse con detalle limitado cuando el producto tiene un propósito justificado. Cualquier recuento, como las últimas diez conversaciones, es una entrada de política ilustrativa y no un valor predeterminado.
Implementación: un resumen por sesión, almacenado con marca temporal y tema. Cuando el usuario regresa, el agente tiene una referencia rápida sobre lo que ha estado ocurriendo recientemente.
{
"session_id": "abc-123",
"user_id": "alice",
"started": "2026-05-14T10:30:00Z",
"ended": "2026-05-14T10:45:00Z",
"topic": "Drafting proposal for Acme Corp",
"summary": "Drafted v1 of the Acme proposal. Decided to lead with the cost-savings angle. Alice will review and send Friday.",
"facts_learned": ["Acme is a current customer", "Alice's deadline is Friday"],
"open_items": ["Alice to review v1 by Thursday"]
}
En una nueva sesión, puede cargarse un subconjunto autorizado de resúmenes recientes después de las pruebas de calidad de recuperación, relevancia, presupuesto de tokens y privacidad. No cargues automáticamente un número fijo en cada contexto por defecto.
Esta es una forma relativamente simple de memoria entre sesiones, pero aún requiere aislamiento, procedencia, corrección, ciclo de vida y pruebas de recuperación.
Capa 3: Memoria episódica
Eventos pasados específicos que vale la pena recordar a largo plazo. Decisiones, hitos, conversaciones importantes.
Estos se extraen de las sesiones cuando son notables. Se almacenan con metadatos ricos.
{
"event_id": "ev-456",
"user_id": "alice",
"date": "2026-04-22",
"type": "decision",
"description": "Alice decided to migrate from Postgres to ClickHouse for the analytics workload, citing query performance.",
"context_summary": "After 3 weeks of evaluation including performance tests and cost analysis.",
"related_topics": ["infrastructure", "analytics", "database"],
"importance": "high"
}
Recuperación: cuando resulta pertinente para la conversación actual, el agente obtiene episodios relacionados. Puede hacerlo mediante búsqueda semántica (vectoriza la consulta actual y busca episodios similares), coincidencia de temas o consultas temporales («¿qué ocurrió el mes pasado?»).
El reto consiste en decidir qué merece conservarse como episodio. Una opción es permitir que un modelo proponga decisiones, compromisos o hitos en un punto de control aprobado, con fragmentos de la fuente y reglas de confirmación. Una etiqueta de importancia generada por el modelo no constituye autorización para conservar datos personales.
Capa 4: Memoria semántica
Hechos estables sobre el usuario que siempre deben estar disponibles. «Alice es la directora ejecutiva de Acme. Prefiere un estilo de comunicación conciso. Trabaja en la zona horaria de Tallin».
Son menos numerosos que los episodios, pero se recuperan con mayor frecuencia. Forman el «modelo del usuario» del agente.
Implementación: un perfil estructurado.
{
"user_id": "alice",
"profile": {
"name": "Alice Tamm",
"role": "CEO at Acme Corp",
"location": "Tallinn, Estonia",
"timezone": "Europe/Tallinn",
"preferred_language": "English",
"communication_style": "concise, direct, no preamble",
"expertise_areas": ["product strategy", "go-to-market"],
"tools_used": ["Notion", "Slack", "Linear"]
}
}
Las actualizaciones ocurren cuando el agente aprende nuevos hechos. Después de una sesión, un LLM identifica nuevos hechos estables y los propone; se fusionan automáticamente o se ponen en cola para revisión.
Importante: los hechos semánticos deben tener alta confianza y ser estables. Un comentario casual en una conversación («Podría probar Python») no debería convertirse en un hecho semántico («Alice prefiere Python»). El listón es más alto.
Un flujo de trabajo de confianza puramente ilustrativo, que aún requiere procedencia y calibración:
- Inferido una vez: solo candidato, con el fragmento fuente y sin efecto conductual automático.
- Declarado explícitamente: candidato para el alcance declarado; confirma antes de una reutilización con consecuencias.
- Confirmado explícitamente: almacenado con procedencia, alcance, fecha de revisión y controles del usuario.
Esto evita que el agente «aprenda» hechos incorrectos a partir de comentarios casuales.
Capa 5: Memoria procedimental
Cómo debe comportarse el agente para este usuario. Flujos de trabajo, plantillas, preferencias para acciones específicas.
Ejemplos:
{
"user_id": "alice",
"procedural": {
"email_signature": "...",
"meeting_preferences": "always offer 3 time slots, never schedule before 9am",
"code_style": "Python, type hints required, dataclasses over dicts",
"tone_for_clients": "warm, direct, with explicit next steps",
"approval_process": "all customer-facing communications need Alice's review before sending"
}
}
Estos son patrones que sigue el agente cuando surgen tareas relevantes.
Las actualizaciones pueden partir de una instrucción explícita o de un patrón repetido. Un comportamiento recurrente puede desencadenar una solicitud de confirmación, pero no debe crear de forma silenciosa un procedimiento persistente.
Opciones de almacenamiento
¿Dónde vive la memoria?
Base de datos SQL. Fiable, consultable y bien conocida. Una tabla por cada tipo de memoria y uniones (joins) para la recuperación. Adecuada para patrones de acceso estructurados.
Base de datos vectorial. Para la recuperación semántica de episodios («encuentra memorias relacionadas con este tema»). Los episodios se vectorizan y se recuperan por similitud.
Combinación. SQL junto con un índice vectorial es una opción cuando se necesitan tanto acceso estructurado como semántico. La representación duplicada aumenta las obligaciones de sincronización y eliminación, así que compárala con un almacén más sencillo.
Herramientas de memoria especializadas. Mem0, Letta (antes MemGPT) y Zep son capas de memoria creadas específicamente para agentes. Conviene evaluarlas si buscas una abstracción de nivel superior.
Comienza con el almacén más pequeño que satisfaga las pruebas de acceso estructurado, recuperación semántica, aislamiento por inquilino, procedencia, corrección, conservación, eliminación, copia de seguridad y recuperación. SQL, un índice vectorial, ambos o una capa especializada pueden ajustarse; compara la carga operativa y de migración en lugar de asumir la opción habitual del equipo.
Patrones de recuperación
¿Cómo introduce el agente la memoria en el contexto?
Patrón 1: Carga automática al inicio de la sesión
Cuando comienza una nueva sesión, extrae automáticamente:
- El perfil semántico del usuario.
- Los últimos N resúmenes de sesiones.
- Cualquier compromiso pendiente o seguimiento.
Este es el contexto base que tiene el agente cuando aparece el usuario.
Patrón 2: Recuperación impulsada por consulta
Cuando el mensaje del usuario sugiere temas pasados, recupera episodios relevantes.
Ejemplo: el usuario pregunta «¿cuál fue la conclusión de nuestra conversación sobre bases de datos?». El agente busca «base de datos» en los episodios y recupera el relevante.
Implementación: vectoriza el mensaje del usuario, encuentra episodios similares e inclúyelos en el contexto.
Patrón 3: Herramientas de memoria explícitas
El agente tiene herramientas para consultar la memoria:
search_episodes(query): encontrar eventos pasados específicos.get_user_profile(): extraer el perfil semántico.list_open_items(): compromisos pendientes.
El agente decide cuándo llamarlas en función de la conversación.
Patrón 4: Enriquecimiento de memoria en segundo plano
Un proceso en segundo plano revisa periódicamente la memoria y:
- Consolida episodios relacionados en temas.
- Actualiza la confianza en los hechos.
- Hace caducar las memorias antiguas a las que no se ha accedido.
Esto es «mantenimiento de la memoria»: mantener el almacén de memoria útil con el tiempo.
Escritura de memoria
¿Cuándo se escribe la memoria?
Extracción por punto de control o fin de sesión
Un patrón por lotes, sujeto a pruebas de entrega duradera y de terminación abrupta. En un punto de control aprobado o al final de la sesión:
- Un LLM analiza la conversación.
- Extrae:
- Resumen de la sesión.
- Eventos notables (para memoria episódica).
- Nuevos hechos (para memoria semántica).
- Señales de preferencia (para memoria procedimental).
- Actualiza y almacena.
El procesamiento por lotes puede reducir el trabajo dentro de la sesión, pero también puede perder actualizaciones cuando una sesión termina inesperadamente y puede retrasar la corrección. Mide ambos comportamientos y usa un trabajo duradero donde se requiera persistencia.
Prompt para extracción:
Analiza esta conversación. Genera un JSON con lo siguiente:
1. summary: resumen de 2-3 oraciones de lo ocurrido.
2. notable_events: array de eventos significativos que vale la pena recordar (decisiones tomadas, hitos, contexto importante).
3. new_facts: array de hechos estables aprendidos sobre el usuario (inclúyelos solo si tienes alta confianza).
4. preference_signals: array de preferencias observadas (solo si se expresan claramente o se repiten).
5. open_items: array de elementos pendientes que el usuario podría querer revisar más adelante.
Sé conservador. Incluye únicamente los elementos con alta confianza. Es mejor omitir algo que alucinar.
Actualizaciones en tiempo real para hechos de alto valor
Para algunos hechos, esperar hasta el final de la sesión es incorrecto. Si un usuario dice «en realidad, mi nombre es Alex, no Alice», la corrección debe aplicarse inmediatamente.
Un patrón: hacer que el agente detecte correcciones explícitas o nuevos hechos importantes en tiempo real y actualice la memoria sobre la marcha.
Esto necesita un diseño cuidadoso: el LLM podría «aprender» hechos incorrectos. Algunos equipos requieren confirmación del usuario antes de aplicar actualizaciones en tiempo real.
Actualizaciones iniciadas por el usuario
El usuario puede decirle explícitamente al agente cosas que recordar:
- «Por favor, recuerda que prefiero X.»
- «Olvida lo que dije sobre Y.»
- «Haz siempre Z.»
Deben ser controles de primer nivel. Inicia de inmediato la acción solicitada, muestra su alcance y estado, y explica cualquier obligación legal de conservación o plazo de caducidad de las copias de seguridad que impida prometer una eliminación universal e instantánea. Una declaración explícita aporta una procedencia sólida, pero no demuestra que todo alcance inferido sea correcto.
Una herramienta específica que el agente puede ofrecer:
remember(content: string, type: "fact" | "preference" | "procedure")
forget(content: string)
list_what_you_remember()
Dar a los usuarios este control genera confianza.
Olvido y caducidad
La memoria sin límites crea riesgos de recuperación, coste, privacidad y precisión. Un ciclo de vida documentado es esencial; la caducidad basada en el tiempo es una opción, no un sustituto para la conservación o eliminación requerida.
Caducidad basada en el tiempo
Las memorias más antiguas tienen menos probabilidad de ser recuperadas. Implementación:
- Puntuar la recuperación por
relevance * recency_decay. - Las memorias antiguas desaparecen en la práctica a menos que se referencien explícitamente.
Conservación basada en la importancia
Los episodios importantes se conservan más tiempo; los triviales caducan más rápido.
- Etiquetar los episodios con su importancia en el momento de la escritura.
- Eventos de alto valor: un período de conservación específico para el propósito, con un propietario y una fecha de revisión; no tomar por defecto la conservación indefinida.
- Eventos rutinarios: caducan a lo largo de meses.
Olvido iniciado por el usuario
El usuario puede solicitar que se eliminen memorias específicas.
- Hechos específicos.
- Períodos de tiempo específicos.
- Temas específicos.
Implementación: un flujo de trabajo de eliminación que elimina el registro principal y todos los fragmentos derivados, embeddings, resúmenes, índices, cachés, exportaciones y trabajos en cola. Una marca de borrado (tombstone) puede impedir la reingesta, pero limitarse a ocultar un registro no es eliminarlo. Define cómo expiran las copias de seguridad y prueba que los datos eliminados no reaparezcan después de la restauración.
Eliminación impulsada por cumplimiento
Los requisitos legales pueden exigir la supresión o la conservación. El artículo 17 del RGPD define un derecho de supresión sujeto a excepciones; la asesoría jurídica debe aplicarlo, junto con las demás reglas pertinentes, al producto, la jurisdicción y el rol de datos.
- Solicitud de eliminación de cuenta de usuario → invoca el flujo de trabajo revisado de eliminación/restricción en los almacenes cubiertos y divulga excepciones o expiración de copia de seguridad.
- Eliminación de datos por solicitud → localiza los registros cubiertos y derivados, luego verifica el resultado.
- Límites de conservación → haz caducar automáticamente los registros cubiertos según el calendario aprobado.
Estos deben integrarse desde el inicio. La adaptación posterior es dolorosa.
Consideraciones de privacidad
La memoria es sensible. El almacén contiene mucha información sobre el usuario. Consideraciones:
Cifrado en reposo
Datos de memoria cifrados. Práctica estándar.
Controles de acceso
¿Quién puede ver la memoria de un usuario? ¿Solo el propio usuario, solo el sistema, el personal de soporte en ciertas condiciones? Defínelo claramente. Audita el acceso.
Manejo de PII
La información personalmente identificable (nombres reales, direcciones, información financiera) debe etiquetarse y tratarse con cuidado. Controles de acceso especiales, procedimientos de eliminación especiales.
Visibilidad del usuario
Donde el producto y los derechos aplicables lo requieran, proporciona una manera para que los usuarios vean, corrijan, acoten y eliminen registros de memoria. Un panel de memoria es una implementación; prueba la comprensión y protégelo como cualquier otra superficie de datos sensibles.
Lo que el agente recuerda sobre ti:
Perfil:
- Nombre: Alice Tamm
- Rol: CEO en Acme Corp
- Estilo de comunicación: conciso y directo
Sesiones recientes:
- 2026-05-14: Redacción de la propuesta para Acme
- 2026-05-12: Revisión de los resultados del primer trimestre
- ...
Preferencias:
- Prefiere respuestas concisas
- Utiliza Notion, Slack y Linear
[Editar] [Eliminar elementos específicos] [Eliminar todo]
Esta transparencia genera confianza. La memoria opaca sin visibilidad para el usuario no la genera.
Compartir entre contextos
Si el usuario tiene múltiples «modos» (agente de trabajo, agente personal), puede querer memorias separadas. No compartas automáticamente entre modos a menos que se solicite.
Modos de fallo comunes
Algunos patrones:
Fallo 1: Memorias alucinadas
El agente afirma recordar cosas que no ocurrieron. «La semana pasada acordamos X» — pero nunca se discutió X.
Causa: el LLM «llenando» memorias con apariencia plausible durante la extracción o recuperación.
Solución: fundamentar las operaciones de memoria en datos reales de la conversación. El LLM extrae; la verificación es contra la transcripción real. Los hechos alucinados deben marcarse como tales.
Fallo 2: Hechos incorrectos aprendidos
El agente afirma con confianza hechos erróneos. «Dijiste que prefieres Python» cuando en realidad dijiste que te obligaron a usar Python en el trabajo.
Causa: mala interpretación durante la extracción.
Solución: umbrales de confianza. Aprende solo de declaraciones explícitas, repetidas o confirmadas. El usuario puede corregir.
Fallo 3: Fugas de privacidad
La memoria de un usuario aparece en la conversación de otro. Catastrófico.
Causa: errores en la lógica de delimitación del alcance por usuario.
Solución: impón el alcance por usuario en las capas de almacenamiento y recuperación. Audita. Nunca confíes en que el LLM filtre.
Fallo 4: Inflación de memoria
Después de un año, la memoria ocupa megabytes por usuario. La recuperación se ralentiza. Los costes crecen.
Causa: sin caducidad o poda.
Solución: caducidad agresiva. La mayor parte de la memoria se vuelve inaccesible (baja prioridad de recuperación) después de meses. Compacción periódica.
Fallo 5: Hechos obsoletos
El usuario cambió de rol hace 6 meses. El agente aún hace referencia al rol antiguo.
Causa: hechos que no se actualizaron al quedar sustituidos.
Solución: detectar contradicciones, preservar la procedencia y las fechas efectivas, y pedir confirmación cuando el valor de referencia no está claro. «El más reciente gana» es inseguro con entradas retrasadas, citadas o maliciosas.
Fallo 6: Consolidación desorientadora
La consolidación de memoria en segundo plano ocasionalmente reescribe memorias de maneras que pierden información.
Causa: resumen agresivo sin preservar hechos clave.
Solución: la consolidación debe preservar los hechos explícitamente. Prueba la consolidación en transcripciones reales de memoria.
Un boceto de implementación: asistente personal con memoria
Un diseño de referencia ilustrativo: un asistente de IA personal para usuarios individuales.
Capas de memoria:
- Trabajo: conversación actual.
- Sesión: últimas 7 sesiones en forma resumida.
- Episódica: 100 eventos notables más recientes, con búsqueda semántica.
- Semántica: perfil del usuario (nombre, rol, preferencias, herramientas).
- Procedimental: flujos de trabajo explícitos que el usuario ha configurado.
Almacenamiento:
- SQL (Postgres): perfil estructurado, sesiones, episodios, procedimientos.
- Base de datos vectorial (pgvector): búsqueda semántica episódica.
Operaciones:
- Al comenzar la sesión: carga automática del perfil semántico + últimas 3 sesiones + elementos pendientes.
- Durante la sesión: recuperación episódica activada por relevancia temática.
- Fin de sesión: extracción basada en LLM; el usuario puede revisar lo que se aprendió.
- Segundo plano: consolidación semanal (combina episodios relacionados, caduca los obsoletos).
Controles del usuario:
- Panel de memoria que muestra lo que se recuerda.
- Editar/eliminar elementos individuales.
- Botón «Olvidar la última hora».
- Flujo de trabajo de eliminación completa de cuenta con cobertura verificada, excepciones documentadas y comportamiento de expiración de copia de seguridad.
Evidencia requerida antes de considerar esto exitoso:
- finalización de tareas con y sin memoria recuperada en un conjunto de evaluación fijo,
- precisión de los hechos almacenados y las memorias recuperadas, incluyendo manejo de contradicciones,
- pruebas de aislamiento entre inquilinos y usuarios,
- propagación de la corrección y la eliminación a través de registros, embeddings, cachés, exportaciones, trabajos y caducidad de las copias de seguridad,
- tokens, almacenamiento, latencia y coste operativo a partir de trazas reales,
- pruebas de comprensión y control del usuario en lugar de confianza asumida.
Modos de fallo abordados:
- Los casos de memoria alucinada se incluyen en las pruebas de extracción y recuperación.
- Las puntuaciones de confianza están calibradas; por sí mismas no hacen que un hecho sea verdadero.
- La autorización se aplica antes de la recuperación y nuevamente antes de la presentación.
- Los trabajos de conservación y consolidación tienen registros de auditoría, manejo de fallos y pruebas de eliminación.
Esta es una lista de verificación de diseño, no prueba de preparación para producción. El estado de producción requiere evidencia de implementación y revisión de seguridad/privacidad.
Herramientas especializadas
Una nota sobre las opciones de memoria como servicio:
Mem0. Una capa de memoria de código abierto. Evalúa su documentación actual y el código contra tus requisitos de persistencia, aislamiento y eliminación.
Letta (MemGPT). Un diseño de memoria orientado a herramientas. Revisa su documentación actual y los límites operativos.
Zep. Un servicio alojado de memoria y contexto. Valida su documentación actual, los límites aplicables a los datos y el contrato de eliminación.
Cognee. Una opción orientada a grafos de conocimiento. Valida su madurez y adecuación a partir de su documentación y repositorio actuales antes de adoptarla.
Estas herramientas pueden reducir el trabajo de implementación y añadir dependencias de proveedor, seguridad, migración y ciclo de vida de datos. Compáralas con un diseño interno usando las mismas pruebas de aceptación.
Construye la memoria mínima justificada
La memoria a largo plazo es lo que hace que los agentes sean continuos entre sesiones en lugar de amnésicos. También es una de las cosas más difíciles de hacer bien.
La arquitectura está en capas:
- Memoria de trabajo (en contexto).
- Memoria de sesión (sesiones recientes).
- Memoria episódica (eventos específicos).
- Memoria semántica (hechos estables).
- Memoria procedimental (preferencias y flujos de trabajo).
Cada capa tiene su propia lógica de almacenamiento, recuperación y caducidad. Cada una contribuye a hacer que el agente sea útil con el tiempo.
Los patrones que importan:
- Extracción conservadora (no alucines hechos).
- Aprendizaje basado en confianza (no aprendas de comentarios casuales).
- Olvido activo (caducidad y poda).
- Control del usuario (transparencia y capacidad de edición).
- Aplicación de privacidad (en cada capa).
Cuando supera las pruebas de evaluación y ciclo de vida, la memoria puede reducir la necesidad de repetir el mismo contexto y hacer que las preferencias confirmadas estén disponibles entre sesiones.
Para agentes que requieren continuidad entre sesiones, la persistencia es una elección explícita del producto. Construye la memoria mínima justificada, con procedencia, autorización, control del usuario y una ruta de fin de vida probada.
