Claude se queda sin puerta de entrada: la caída de autenticación del 13 de noviembre
Numerosos usuarios de Claude se encontraron el viernes 13 de noviembre de 2026 con una pantalla que no avanzaba: el inicio de sesión fallaba y el acceso al asistente quedaba bloqueado. A las 09:58 UTC, Anthropic abrió en su página de estado un incidente por problemas de los usuarios para autenticarse en Claude.ai y en Claude Code, su herramienta de programación asistida por agentes. El servicio web quedó marcado como caída mayor, mientras que Claude Code y la Console, el panel de gestión para desarrolladores, aparecían con caídas parciales. La API, en cambio, no figuraba entre los componentes afectados en ese primer aviso.
De acuerdo con reportes, la compañía desplegó una corrección hacia las 11:05 UTC y dio el incidente por resuelto hacia las 11:58 UTC, unas dos horas después de su apertura. Sin embargo, la jornada no terminó ahí: a las 13:09 UTC se abrió un segundo incidente, independiente del primero, con tasas de error elevadas en claude.ai, la API y Claude Code, que se prolongó buena parte de la tarde europea.
El episodio llega en un momento especialmente sensible para Anthropic. Apenas cuatro días antes la empresa había presentado su nueva generación de modelos, y esa misma semana se encontraba inmersa en el roadshow previo a su salida a bolsa, con la cotización prevista para el 19 de noviembre. A ello se suma un contexto en el que otras plataformas críticas, como Microsoft 365, también sufrieron interrupciones globales en los mismos días. La compañía no ha divulgado la causa raíz del fallo de autenticación, y su aviso público no contenía ninguna recomendación de cambiar contraseñas ni mención a filtraciones de datos o credenciales comprometidas.
Cronología de una mañana sin acceso
La secuencia de los hechos, reconstruida a partir de la página de estado de la compañía y de reportes posteriores, permite entender la magnitud del problema y la velocidad de la respuesta.
A las 09:58 UTC, cuando en buena parte de Europa ya avanzaba la jornada laboral y en la costa este de Estados Unidos apenas comenzaba la madrugada, Anthropic publicó el primer aviso. El texto se limitaba a reconocer que los usuarios estaban teniendo problemas para autenticarse en Claude.ai y Claude Code. No había más detalles técnicos, algo habitual en las primeras fases de cualquier incidente, cuando los equipos de ingeniería todavía están acotando el alcance del fallo.
La clasificación de los componentes ofrecía, no obstante, información valiosa. Claude.ai aparecía en rojo, con la etiqueta de caída mayor, lo que indica que la mayoría de los usuarios del producto web no podían utilizarlo con normalidad. Claude Code y la Console, por su parte, figuraban con caídas parciales: algunas sesiones funcionaban y otras no, probablemente en función de si el usuario necesitaba iniciar sesión de nuevo o mantenía una sesión activa. Esta última interpretación es razonable desde el punto de vista técnico, pero la empresa no la ha confirmado, por lo que conviene tomarla con prudencia.
Durante la hora siguiente, los usuarios afectados se volcaron en foros y redes sociales para comprobar si el problema era generalizado o local. Es un patrón conocido: cuando un servicio de uso intensivo deja de responder, la primera reacción de muchos profesionales es descartar que el fallo esté en su propia red, en su navegador o en su configuración.
Según reportes, hacia las 11:05 UTC Anthropic desplegó una corrección. A partir de ese momento la situación comenzó a normalizarse de forma progresiva, algo coherente con la manera en que suelen propagarse los cambios en infraestructuras distribuidas, donde una solución no llega a todos los nodos y regiones en el mismo instante. Finalmente, hacia las 11:58 UTC, el incidente quedó marcado como resuelto en la página de estado.
En total, la ventana entre la apertura del aviso y su cierre fue de aproximadamente dos horas. Para un usuario ocasional puede parecer un contratiempo menor; para un equipo de desarrollo que tiene integrado el asistente en su flujo diario, o para una empresa que lo utiliza en atención al cliente o en procesos internos, dos horas sin acceso pueden traducirse en tareas bloqueadas, entregas retrasadas y una cola de trabajo pendiente.
Qué servicios se vieron afectados y cuáles no
Uno de los aspectos más relevantes del primer incidente es su perímetro. No todos los productos de Anthropic sufrieron por igual, y esa distinción tiene implicaciones prácticas para quienes construyen sobre la plataforma.
Claude.ai, la aplicación de chat que utilizan millones de personas, fue el componente más castigado. Al tratarse de un producto orientado al usuario final, depende directamente del sistema de inicio de sesión: sin autenticación no hay acceso a conversaciones, proyectos ni archivos.
Claude Code, la herramienta de línea de comandos que permite delegar tareas de programación a agentes de IA, también se vio afectada, aunque de forma parcial. En los últimos meses se ha convertido en una pieza central del día a día de muchos desarrolladores, que la usan para refactorizar código, escribir pruebas, revisar cambios o automatizar tareas repetitivas. Cuando un usuario necesita autenticarse con su cuenta para usarla, cualquier problema en ese paso le deja fuera.
La Console, el entorno web desde el que los desarrolladores gestionan claves, consumo y configuración de la API, apareció igualmente con caída parcial. Esto podía impedir, por ejemplo, generar una nueva clave o revisar el uso durante el incidente, aunque no necesariamente afectaba a las llamadas que ya se estaban realizando con claves existentes.
La API, en cambio, no figuraba como afectada en el primer incidente. Es un matiz importante: las aplicaciones que integran los modelos de Anthropic mediante llamadas programáticas con clave de API no dependen del mismo flujo de inicio de sesión que utiliza una persona al entrar en la web. En otras palabras, el problema afectó a la puerta de entrada de los productos, no necesariamente al motor que hay detrás. Esta diferencia, sobre la que se volverá más adelante, es una de las lecciones técnicas más útiles del episodio.
Un segundo incidente en la misma jornada
Cuando la situación parecía controlada, la página de estado volvió a registrar actividad. A las 13:09 UTC Anthropic abrió un incidente separado, esta vez por tasas de error elevadas en claude.ai, la API y Claude Code. A diferencia del primero, este sí alcanzaba a la API, lo que ampliaba el impacto a las integraciones de terceros y a las aplicaciones empresariales que consumen los modelos de forma programática.
A las 15:33 UTC la compañía informó de la recuperación en claude.ai y la API, aunque advirtió de que los errores podían reaparecer. Ese tipo de matiz es significativo: indica que el equipo había estabilizado el servicio, pero que todavía no tenía la certeza de que el problema subyacente estuviera completamente eliminado.
Además, Anthropic indicó que las tareas programadas se ejecutaron con más de dos horas de retraso y que algunas se omitieron. Para los usuarios que habían configurado trabajos recurrentes, este detalle tiene consecuencias concretas: un informe que debía generarse a primera hora pudo llegar con retraso, y una tarea que debía ejecutarse en una franja concreta pudo no ejecutarse nunca. En procesos encadenados, donde un paso alimenta al siguiente, una omisión silenciosa puede tener efectos en cascada si nadie la detecta a tiempo.
La empresa no ha establecido públicamente una relación entre ambos incidentes, y los presentó como eventos separados. Sería especulativo afirmar que uno fue consecuencia del otro o que comparten una causa común. Lo que sí puede constatarse es que, para el usuario final, la experiencia del 13 de noviembre fue la de una jornada con dos ventanas de inestabilidad distintas, una por la mañana y otra por la tarde en horario europeo.
Lo que Anthropic ha comunicado y lo que no
La comunicación durante los incidentes se ha canalizado a través de la página de estado, que es la vía habitual de las grandes plataformas para informar en tiempo real. Los avisos fueron breves y descriptivos: reconocían el problema, enumeraban los componentes afectados y, en su momento, informaban de la corrección y la resolución.
Lo que no ha llegado, al menos hasta el momento de redactar esta información, es una explicación de la causa raíz del fallo de autenticación. Anthropic no ha detallado si el origen estuvo en un cambio de configuración, en un proveedor externo, en un despliegue de software o en cualquier otro factor. Cualquier hipótesis al respecto carece, por ahora, de respaldo oficial.
Hay otro dato que conviene subrayar para evitar alarmas innecesarias. El aviso no pedía a los usuarios que cambiaran sus contraseñas ni hacía referencia a filtraciones de datos o a credenciales comprometidas. Cuando un sistema de autenticación falla, es frecuente que surjan dudas sobre la seguridad de las cuentas. Con la información disponible, nada indica que el incidente tuviera esa naturaleza, aunque la ausencia de un análisis detallado impide descartarlo todo de forma categórica. Lo prudente, como siempre, es mantener buenas prácticas de higiene digital, como la verificación en dos pasos, sin extraer conclusiones que la compañía no ha comunicado.
En la industria es cada vez más común que, días o semanas después de un incidente relevante, las empresas publiquen un informe postmortem con la cronología técnica, la causa identificada y las medidas adoptadas para evitar que se repita. Si Anthropic sigue ese camino, el documento será la fuente de referencia para entender lo ocurrido. Mientras tanto, la información disponible se limita a lo publicado en la página de estado y a lo recogido en reportes posteriores.
Un momento delicado: Fable 5.2 y la salida a bolsa
El calendario no ha jugado a favor de Anthropic. El 9 de noviembre, apenas cuatro días antes de la caída, la compañía había llevado a cabo el lanzamiento de Claude Fable 5.2, una actualización de su familia de modelos con la que buscaba reforzar su posición frente a la competencia en tareas de programación y razonamiento. Los lanzamientos de nuevos modelos suelen ir acompañados de picos de tráfico, ya que desarrolladores y empresas se apresuran a probar las novedades y a comparar resultados.
No hay información oficial que vincule el incidente con el lanzamiento, y establecer esa relación sería pura especulación. Sin embargo, el contexto ayuda a entender por qué la caída tuvo tanta repercusión: se produjo en una semana en la que la atención sobre la empresa era máxima.
A ello se añade el factor financiero. Anthropic se encontraba en plena semana del roadshow de su salida a bolsa, con la cotización prevista para el 19 de noviembre. Durante ese periodo, los directivos de una compañía presentan su negocio ante inversores institucionales, defienden sus métricas y transmiten confianza en la solidez de su plataforma. Una interrupción visible del servicio, aunque se resuelva en un par de horas, inevitablemente se convierte en tema de conversación y pone el foco en la fiabilidad de la infraestructura.
Para los inversores, la disponibilidad del servicio es un indicador relevante en cualquier empresa tecnológica que vende acceso a su producto mediante planes mensuales o por consumo. Para los clientes empresariales, es una cuestión contractual y operativa. Y para los desarrolladores individuales, es sencillamente la diferencia entre poder trabajar o no. Que el incidente coincida con un momento de tanta exposición pública no cambia su naturaleza técnica, pero sí amplifica su eco.
Antecedentes: cuando la nube y la IA se detienen
La caída de Claude no es un caso aislado. La historia reciente de la infraestructura digital está jalonada de interrupciones que han recordado, una y otra vez, que incluso los proveedores más grandes y mejor dotados sufren fallos.
Esa misma semana se produjo una caída global de Microsoft 365, que afectó a herramientas de productividad utilizadas por millones de organizaciones en todo el mundo. La coincidencia temporal de ambos episodios ha alimentado la conversación sobre la fragilidad de un ecosistema en el que una gran parte del trabajo diario depende de un número reducido de plataformas.
Si se mira un poco más atrás, los ejemplos abundan. El 20 de octubre de 2025, la región US-EAST-1 de Amazon Web Services sufrió una interrupción de gran alcance vinculada, según la propia compañía, a la resolución DNS del punto de acceso de la API de DynamoDB. El problema se propagó en cascada a otros servicios de la región y, de acuerdo con análisis posteriores, la degradación se prolongó durante más de quince horas, afectando a numerosas aplicaciones y plataformas que dependen de esa infraestructura.
Menos de un mes después, el 18 de noviembre de 2025, Cloudflare vivió una de sus caídas más severas en años. Según el informe publicado por la empresa, un cambio de permisos en un sistema de base de datos provocó que un archivo de configuración utilizado por su sistema de gestión de bots duplicara su tamaño, superando un límite interno del software de proxy y provocando fallos en la entrega de tráfico a escala global. Miles de sitios web dejaron de estar accesibles durante horas.
Y en julio de 2024, una actualización defectuosa de CrowdStrike dejó fuera de servicio unos 8,5 millones de dispositivos Windows según estimaciones de Microsoft, paralizando aerolíneas, hospitales y bancos. Aquel episodio, aunque no fue una caída de un servicio en la nube en sentido estricto, se convirtió en un símbolo de cómo un único fallo en un componente ampliamente distribuido puede tener consecuencias globales.
Los servicios de IA generativa tampoco son ajenos a este fenómeno. Desde que los asistentes conversacionales y las API de modelos se convirtieron en herramientas de uso masivo, los principales proveedores del sector han registrado interrupciones periódicas, a menudo relacionadas con picos de demanda, despliegues o dependencias de infraestructura. La diferencia respecto a hace unos años es que hoy estas herramientas ya no son un experimento: están integradas en flujos de trabajo profesionales, productos comerciales y procesos empresariales, por lo que su indisponibilidad tiene un coste real.
Impacto para desarrolladores y empresas
El alcance de una caída se mide no solo por su duración, sino por la profundidad con la que el servicio está integrado en la actividad de quienes lo usan. En el caso de Claude, el impacto se distribuyó de forma desigual entre distintos perfiles.
Los desarrolladores que trabajan con Claude Code como parte de su rutina diaria fueron, probablemente, los que más notaron el primer incidente. Quien tenía una sesión activa pudo seguir trabajando en algunos casos, pero quien necesitaba iniciar sesión, cambiar de máquina o reautenticarse se encontró bloqueado. Para equipos que han reorganizado su forma de programar en torno a agentes de IA, perder esa herramienta durante dos horas obliga a volver al flujo manual, con la consiguiente pérdida de ritmo.
Los usuarios de Claude.ai, tanto particulares como profesionales, se quedaron sin acceso a sus conversaciones y proyectos. En entornos corporativos donde el asistente se usa para redactar documentación, analizar información o preparar presentaciones, la interrupción supuso aplazar tareas o buscar alternativas sobre la marcha.
Las empresas que integran los modelos mediante la API vivieron una jornada distinta. Durante el primer incidente, según la página de estado, la API no estaba afectada, por lo que las aplicaciones que dependían exclusivamente de ella pudieron seguir funcionando. El segundo incidente, en cambio, sí incluyó tasas de error elevadas en la API, lo que pudo traducirse en peticiones fallidas, respuestas lentas o reintentos acumulados en productos de terceros. Para un servicio de atención al cliente basado en IA o una plataforma que genera contenido bajo demanda, cada error se traduce en una experiencia degradada para sus propios usuarios.
Por último, quienes habían configurado tareas programadas se encontraron con retrasos de más de dos horas y, en algunos casos, con ejecuciones que directamente no se produjeron. Este es quizá el impacto más difícil de detectar, porque no siempre genera un error visible: simplemente, algo que debía ocurrir no ocurre, y el problema solo se descubre cuando alguien echa en falta el resultado.
En términos más amplios, el episodio vuelve a poner sobre la mesa una cuestión estratégica que muchas organizaciones todavía no han abordado con seriedad: la dependencia de un único proveedor de IA. Cuando todo un flujo de trabajo, un producto o un proceso interno descansa sobre un solo modelo y una sola plataforma, cualquier interrupción de ese proveedor se convierte automáticamente en una interrupción propia.
La situación al momento de escribir
Al cierre de esta información, el primer incidente, el relacionado con la autenticación en Claude.ai y Claude Code, figura como resuelto desde aproximadamente las 11:58 UTC del 13 de noviembre. El segundo, el de las tasas de error elevadas, contó con un aviso de recuperación en claude.ai y la API a las 15:33 UTC, acompañado de la advertencia de que los errores podían reaparecer.
Anthropic no ha publicado, hasta donde ha podido comprobarse, un análisis de causa raíz de ninguno de los dos incidentes. Tampoco ha emitido recomendaciones adicionales de seguridad para los usuarios, más allá de lo recogido en la página de estado, que no incluía peticiones de cambio de contraseña ni referencias a credenciales comprometidas.
Para quienes tuvieran tareas programadas en esa franja, la recomendación práctica es revisar qué trabajos se ejecutaron con retraso y cuáles no llegaron a ejecutarse, dado que la propia compañía reconoció que algunas se omitieron. En los casos en que el resultado sea importante, puede ser necesario relanzarlas manualmente.
Queda pendiente, además, comprobar cómo evoluciona la estabilidad del servicio en los próximos días, en una semana marcada por la expectación ante la salida a bolsa y por el previsible aumento de uso tras el lanzamiento de los nuevos modelos.
Análisis: autenticación del producto frente a disponibilidad de la API
Uno de los aprendizajes más interesantes de esta jornada tiene que ver con la arquitectura de los servicios de IA y con cómo se distribuyen los puntos de fallo. Para un usuario que solo conoce la interfaz web, “Claude no funciona” es una frase que lo resume todo. Para un equipo técnico, en cambio, conviene distinguir entre capas.
Por un lado está la capa de producto: la aplicación web, las aplicaciones de escritorio y móviles, la herramienta de línea de comandos. Estas interfaces requieren que una persona se identifique con su cuenta, normalmente a través de un flujo de inicio de sesión que puede implicar proveedores de identidad, gestión de sesiones y tokens. Si ese flujo falla, el usuario no puede pasar de la puerta, aunque los modelos estén funcionando perfectamente al otro lado.
Por otro lado está la capa de API, que es la que utilizan las aplicaciones de terceros. Aquí la identificación suele realizarse con claves de API asociadas a una organización, un mecanismo diferente al inicio de sesión de una persona. Por eso es posible que el producto web esté caído mientras la API sigue respondiendo con normalidad, como ocurrió en el primer incidente según la página de estado.
Esta separación tiene consecuencias de diseño. Un equipo que haya construido su producto sobre la API pudo seguir operando durante la mañana del 13 de noviembre, mientras que un equipo cuyo flujo de trabajo dependía del producto web o de la herramienta con inicio de sesión se quedó bloqueado. Conocer qué capa utiliza cada proceso de una organización permite evaluar mejor el riesgo y preparar alternativas adecuadas.
Al mismo tiempo, el segundo incidente demuestra que la API no es inmune. Las tasas de error elevadas afectaron también a las llamadas programáticas, lo que recuerda que la separación entre capas reduce el riesgo, pero no lo elimina. Ningún componente de un sistema distribuido debe considerarse infalible.
Este tipo de análisis es especialmente relevante para los equipos de plataforma y operaciones, que tienen que decidir cómo exponer las herramientas de IA dentro de sus organizaciones. Ofrecer acceso a los modelos a través de una pasarela interna conectada a la API, en lugar de depender exclusivamente de las aplicaciones de consumo, puede ser una forma de ganar control sobre la disponibilidad, los costes y la posibilidad de cambiar de proveedor cuando sea necesario.
Lecciones de resiliencia para equipos que dependen de la IA
Las caídas, por molestas que resulten, son también oportunidades para revisar la arquitectura y los procesos. El episodio del 13 de noviembre deja una serie de lecciones aplicables a cualquier equipo que trabaje con servicios de IA en la nube, independientemente del proveedor.
La primera tiene que ver con la gestión de errores en las integraciones. Cuando una API devuelve errores transitorios, la reacción más ingenua es reintentar inmediatamente y de forma indefinida, lo que puede agravar la saturación del servicio y bloquear la propia aplicación. La práctica recomendada consiste en aplicar reintentos con backoff exponencial y un componente aleatorio, de manera que cada nuevo intento espere progresivamente más tiempo y los clientes no golpeen el servicio todos a la vez. Conviene, además, fijar un número máximo de intentos y un tiempo límite global, y combinarlo con patrones como el cortocircuito, que detiene temporalmente las llamadas cuando la tasa de fallos supera un umbral.
La segunda lección es la redundancia a nivel de modelo. Los equipos que dependen de la IA para funciones críticas deberían plantearse un fallback a modelos alternativos cuando el proveedor principal no responde. Esto puede significar recurrir a otro modelo del mismo proveedor desplegado en una infraestructura diferente, como una plataforma de nube que lo ofrezca, o a un modelo de otro proveedor con capacidades comparables. La clave está en diseñar una capa de abstracción que permita cambiar de modelo sin reescribir la aplicación, y en probar periódicamente que esa alternativa funciona de verdad, porque un plan de contingencia que nunca se ha ejercitado suele fallar justo cuando se necesita. Hay que asumir, eso sí, que cada modelo responde de forma distinta, por lo que los prompts y las validaciones de salida deben estar preparados para ello.
La tercera lección se refiere a la observabilidad. Monitorizar la página de estado del proveedor es un primer paso sencillo y útil: muchas plataformas ofrecen avisos por correo, canales de mensajería o fuentes que permiten recibir avisos automáticos. Pero la página de estado no siempre refleja un problema en el mismo instante en que empieza a afectar a una integración concreta. Por eso es recomendable complementar esa información con métricas propias: tasa de errores por proveedor, latencia de las respuestas, número de reintentos y alertas configuradas sobre esos indicadores. Así, el equipo puede detectar la degradación antes incluso de que se publique el aviso oficial.
La cuarta lección, quizá la menos evidente, afecta a los procesos automatizados. La confirmación de que algunas ejecuciones se retrasaron más de dos horas y otras se omitieron pone de relieve la importancia de diseñar tareas programadas idempotentes, es decir, trabajos que puedan ejecutarse varias veces sin producir efectos duplicados ni resultados inconsistentes. Si una tarea es idempotente, relanzarla tras un fallo es seguro; si no lo es, cada reintento puede generar registros duplicados, notificaciones repetidas o datos corruptos. A esto se suma la necesidad de que cada tarea deje constancia de su ejecución y de su resultado, de forma que un proceso de vigilancia pueda detectar las que no se han completado y avisar al responsable.
La quinta lección es organizativa. Más allá de la técnica, conviene que los equipos tengan definido qué hacer cuando una herramienta de IA deja de estar disponible: quién decide activar la alternativa, cómo se comunica a los usuarios internos o a los clientes, qué tareas pueden aplazarse y cuáles deben resolverse por otras vías. Un pequeño manual de actuación, revisado periódicamente, ahorra improvisación en el momento crítico.
Por último, el episodio invita a reflexionar sobre la gestión de la autenticación en las herramientas de desarrollo. Los profesionales que trabajan con asistentes que requieren inicio de sesión pueden valorar si existen modos alternativos de acceso, por ejemplo mediante claves de API gestionadas por la organización, que les permitan seguir trabajando cuando el flujo de inicio de sesión del producto falla. No siempre será posible ni recomendable, pero conocer las opciones disponibles ayuda a reducir el tiempo de bloqueo.
Ninguna de estas medidas elimina por completo el riesgo, y todas tienen un coste en complejidad, mantenimiento y presupuesto. La decisión de cuánto invertir en resiliencia depende de lo crítico que sea el servicio para cada organización. Para un uso exploratorio, esperar a que el proveedor resuelva la incidencia puede ser suficiente. Para un producto comercial que atiende a clientes en tiempo real, la redundancia deja de ser un lujo y se convierte en un requisito.
Conclusiones
La caída de autenticación del 13 de noviembre de 2026 dejó a los usuarios de Claude.ai y Claude Code sin acceso durante unas dos horas, en un incidente que Anthropic abrió a las 09:58 UTC y dio por resuelto hacia las 11:58 UTC. La API no figuraba como afectada en ese primer episodio, pero un segundo incidente, abierto a las 13:09 UTC, sí provocó tasas de error elevadas en la API y en los productos, con retrasos de más de dos horas y omisiones en tareas programadas.
La compañía no ha explicado todavía la causa raíz, y su comunicación no incluyó peticiones de cambio de contraseña ni referencias a filtraciones de datos. Cualquier hipótesis sobre el origen del fallo carece, por ahora, de respaldo oficial, y lo más razonable es esperar a un eventual análisis técnico detallado.
El contexto amplifica la repercusión del episodio: la caída llega días después de la presentación de Claude Fable 5.2 y en plena semana del roadshow de la salida a bolsa de Anthropic, con la cotización prevista para el 19 de noviembre. Coincide, además, con otras interrupciones de alto perfil, como la de Microsoft 365, y se suma a una lista de antecedentes que incluye las caídas de AWS y Cloudflare en 2025 o el incidente de CrowdStrike en 2024.
Para desarrolladores y empresas, la lección de fondo es conocida pero no siempre aplicada: los servicios de IA en la nube fallan, como falla cualquier infraestructura. Distinguir entre la capa de producto y la de API, gestionar los errores con reintentos bien diseñados, preparar alternativas con otros modelos, vigilar tanto la página de estado como las métricas propias y construir procesos automatizados capaces de recuperarse sin efectos secundarios son medidas que marcan la diferencia entre una mañana perdida y una incidencia apenas perceptible. A medida que la IA se integra en más procesos críticos, la resiliencia deja de ser una cuestión secundaria y pasa a formar parte del diseño desde el primer día.