{"id":81149,"date":"2026-09-18T13:52:38","date_gmt":"2026-09-18T16:52:38","guid":{"rendered":"https:\/\/a3aengenharia.com\/?post_type=articles&p=81149"},"modified":"2026-09-18T13:52:38","modified_gmt":"2026-09-18T16:52:38","slug":"technical-authority-ingenieria-independencia-gobernanza-decisiones","status":"publish","type":"articles","link":"https:\/\/a3aengenharia.com\/es-es\/contenido\/articulos-tecnicos\/technical-authority-ingenieria-independencia-gobernanza-decisiones\/","title":{"rendered":"Technical Authority en Ingenier\u00eda: autoridad t\u00e9cnica, independencia y gobernanza de decisiones"},"content":{"rendered":"\n

Technical Authority<\/strong> \u00e9 um mecanismo de governan\u00e7a pelo qual uma organiza\u00e7\u00e3o delega autoridade t\u00e9cnica formal a pessoas ou fun\u00e7\u00f5es qualificadas para estabelecer, interpretar, manter e defender requisitos, crit\u00e9rios e posi\u00e7\u00f5es t\u00e9cnicas dentro de limites definidos. O objetivo n\u00e3o \u00e9 criar uma segunda gest\u00e3o do projeto, mas assegurar que decis\u00f5es relevantes para seguran\u00e7a, desempenho, integridade, conformidade e arquitetura sejam avaliadas por uma inst\u00e2ncia t\u00e9cnica com compet\u00eancia e mandato claros.<\/p>\n\n\n\n

En proyectos de ingenier\u00eda, la necesidad aparece cuando plazo, costo, alcance, inter\u00e9s comercial o presi\u00f3n operacional pueden competir con requisitos t\u00e9cnicos. Sin una arquitectura de autoridad, las decisiones cr\u00edticas tienden a depender de influencia informal, seniority percibida o negociaci\u00f3n entre \u00e1reas. Con una estructura formal, queda definido qui\u00e9n puede aprobar desviaciones, qui\u00e9n interpreta requisitos, qui\u00e9n acepta riesgos t\u00e9cnicos dentro de determinada autoridad y cu\u00e1ndo una cuesti\u00f3n debe escalarse.<\/p>\n\n\n\n

Technical Authority no elimina la responsabilidad del gerente de proyecto, del sponsor ni del propietario. Separa perspectivas complementarias: la gesti\u00f3n sigue siendo responsable de la entrega y de los compromisos del proyecto, mientras la autoridad t\u00e9cnica protege criterios, requisitos y l\u00edmites t\u00e9cnicos que no deber\u00edan modificarse sin una evaluaci\u00f3n y aprobaci\u00f3n adecuadas.<\/p>\n\n\n\n

Technical Authority es una funci\u00f3n de gobernanza, no un cargo gen\u00e9rico<\/h2>\n\n\n\n

El t\u00e9rmino puede designar una persona, una funci\u00f3n o una cadena de delegaci\u00f3n. El elemento esencial es la combinaci\u00f3n de competencia t\u00e9cnica, autoridad formal, independencia suficiente y rendici\u00f3n de cuentas<\/strong>.<\/p>\n\n\n\n

NASA utiliza Technical Authority como parte de su sistema de checks and balances, separando autoridad program\u00e1tica y autoridad t\u00e9cnica para que las decisiones no se tomen de forma aislada. En empresas de ingenier\u00eda, infraestructura y activos industriales, el mismo principio puede adaptarse sin copiar la estructura institucional de NASA: disciplinas y sistemas cr\u00edticos reciben autoridades expl\u00edcitamente definidas para requisitos, est\u00e1ndares, desviaciones y decisiones t\u00e9cnicas.<\/p>\n\n\n\n

Esto es diferente de simplemente nombrar al profesional m\u00e1s experimentado. La seniority sin mandato formal no resuelve conflictos de decisi\u00f3n; un mandato sin competencia t\u00e9cnica tampoco.<\/p>\n\n\n\n\n

Gobernanza y gesti\u00f3n deben permanecer diferenciadas<\/h2>\n\n\n\n

ABNT NBR ISO 21505 diferencia gobernanza y gesti\u00f3n: la gobernanza autoriza, dirige, establece l\u00edmites y supervisa; la gesti\u00f3n opera dentro de esas restricciones para alcanzar los objetivos organizacionales.<\/p>\n\n\n\n

Una estructura de Technical Authority se sit\u00faa en esa frontera. No debe elaborar el cronograma, administrar contrataciones ni sustituir la coordinaci\u00f3n cotidiana. Su funci\u00f3n es asegurar que determinadas decisiones t\u00e9cnicas respeten principios, requisitos, tolerancias y criterios definidos por la organizaci\u00f3n.<\/p>\n\n\n\n

Esta separaci\u00f3n evita dos errores: transformar la autoridad t\u00e9cnica en un gerente paralelo del proyecto o, en el extremo opuesto, dejarla sin poder real para impedir una decisi\u00f3n t\u00e9cnicamente inadecuada.<\/p>\n\n\n\n

\n

La autoridad t\u00e9cnica debe nacer dentro del framework de gobernanza.<\/strong> Mandato, l\u00edmites, rendici\u00f3n de cuentas y escalamiento deben ser expl\u00edcitos para que las decisiones t\u00e9cnicas no dependan \u00fanicamente de una jerarqu\u00eda informal.<\/p>\n\n\n

Gobernanza de Proyectos, Programas y Portafolios \u2192<\/strong><\/a><\/p>\n<\/div>\n\n\n\n

La autoridad t\u00e9cnica necesita una cadena expl\u00edcita de delegaci\u00f3n<\/h2>\n\n\n\n

Una organizaci\u00f3n madura puede responder qui\u00e9n concedi\u00f3 la autoridad, sobre qu\u00e9 dominio, con qu\u00e9 l\u00edmites y durante cu\u00e1nto tiempo. La delegaci\u00f3n puede ser corporativa, por disciplina, sistema, activo, programa o proyecto.<\/p>\n\n\n\n

Elemento<\/td>Definici\u00f3n esperada<\/td><\/tr>
dominio<\/td>disciplina, sistema, activo o requisito cubierto<\/td><\/tr>
autoridad<\/td>decisiones que la funci\u00f3n puede tomar o aprobar<\/td><\/tr>
l\u00edmites<\/td>valor, riesgo, criticidad, fase o tipo de desviaci\u00f3n<\/td><\/tr>
escalamiento<\/td>autoridad superior para conflitos ou exce\u00e7\u00f5es<\/td><\/tr>
sustituci\u00f3n<\/td>qui\u00e9n responde en caso de ausencia o impedimento<\/td><\/tr>
evidencia<\/td>registro formal de la decisi\u00f3n y su justificaci\u00f3n<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

O objetivo \u00e9 impedir que a autoridad exista apenas como percep\u00e7\u00e3o cultural. Uma decis\u00e3o t\u00e9cnica relevante precisa ser rastre\u00e1vel ao mandato que permitiu tom\u00e1-la.<\/p>\n\n\n\n\n

Technical Authority y Project Assurance no son lo mismo<\/h2>\n\n\n\n

O Project Assurance en Ingenier\u00eda<\/a> aporta confianza independiente a la gobernanza sobre si el proyecto se est\u00e1 conduciendo adecuadamente y si riesgos, procesos, requisitos y controles est\u00e1n funcionando. Technical Authority tiene otra responsabilidad: tomar, aprobar o sostener determinadas posiciones t\u00e9cnicas dentro de una autoridad formal<\/strong>.<\/p>\n\n\n\n

Assurance puede recomendar que un requisito no est\u00e1 adecuadamente controlado. La autoridad t\u00e9cnica puede ser la instancia responsable de decidir sobre la interpretaci\u00f3n de ese requisito, aprobar una excepci\u00f3n o rechazar la desviaci\u00f3n.<\/p>\n\n\n\n

En organizaciones peque\u00f1as, la misma persona puede acumular funciones, pero los roles deben seguir conceptualmente separados para evitar autoevaluaci\u00f3n y conflictos de inter\u00e9s.<\/p>\n\n\n\n

Technical Authority y Design Authority tambi\u00e9n deben diferenciarse<\/h2>\n\n\n\n

Design Authority suele estar asociada a la integridad de una soluci\u00f3n, arquitectura o configuraci\u00f3n de dise\u00f1o. Technical Authority puede tener un alcance m\u00e1s amplio, incluyendo pol\u00edticas, requisitos, est\u00e1ndares, criterios de ingenier\u00eda, seguridad, m\u00e9todos y excepciones.<\/p>\n\n\n\n

En algunos contextos, Design Authority es una manifestaci\u00f3n espec\u00edfica de la autoridad t\u00e9cnica sobre el dise\u00f1o. En otros, la organizaci\u00f3n separa autoridad por disciplina, sistema y arquitectura. El nombre es menos importante que la definici\u00f3n expl\u00edcita de responsabilidad.<\/p>\n\n\n\n

O Design Management en Ingenier\u00eda<\/a> organiza el proceso de desarrollo del proyecto; Technical Authority establece o protege l\u00edmites decisorios que ese proceso debe respetar.<\/p>\n\n\n\n\n

Los requisitos t\u00e9cnicos necesitan un propietario de autoridad<\/h2>\n\n\n\n

A Gesti\u00f3n de Requisitos en Ingenier\u00eda<\/a> funciona mejor cuando los requisitos cr\u00edticos tienen origen, responsable, m\u00e9todo de verificaci\u00f3n y autoridad definida para interpretaci\u00f3n y cambio.<\/p>\n\n\n\n

No todo requisito exige aprobaci\u00f3n de una Technical Authority. El modelo debe ser proporcional. Los requisitos de seguridad, desempe\u00f1o cr\u00edtico, interfaces sist\u00e9micas, cumplimiento regulatorio, capacidad, disponibilidad, protecci\u00f3n e integridad estructural o funcional tienden a exigir controles m\u00e1s fuertes.<\/p>\n\n\n\n

Cuando no existe una autoridad definida, las solicitudes de cambio pueden circular por varias \u00e1reas hasta que prevalezca la decisi\u00f3n de quien tenga mayor influencia circunstancial.<\/p>\n\n\n\n

\n

Los requisitos cr\u00edticos necesitan una autoridad definida para interpretaci\u00f3n y cambio.<\/strong> La trazabilidad t\u00e9cnica pierde fuerza cuando nadie sabe qui\u00e9n puede aceptar una desviaci\u00f3n, modificar la baseline o reconocer la evidencia de cumplimiento.<\/p>\n\n\n

Gesti\u00f3n de Requisitos, Evidencias y Criterios de Aceptaci\u00f3n \u2192<\/strong><\/a><\/p>\n<\/div>\n\n\n\n

Las desviaciones, waivers y excepciones necesitan autoridad t\u00e9cnica<\/h2>\n\n\n\n

Los proyectos reales conviven con incompatibilidades de campo, indisponibilidad de equipos, cambios de proveedor, restricciones de plazo y nueva informaci\u00f3n. La gobernanza t\u00e9cnica no debe fingir que las desviaciones no existir\u00e1n; debe definir c\u00f3mo ser\u00e1n evaluadas.<\/p>\n\n\n\n

Una solicitud de desviaci\u00f3n t\u00e9cnicamente controlada deber\u00eda identificar el requisito afectado, la condici\u00f3n propuesta, la justificaci\u00f3n, alternativas evaluadas, impactos en seguridad, desempe\u00f1o, confiabilidad, interfaces, costo y plazo, riesgos residuales, verificaciones adicionales y la autoridad necesaria para aprobaci\u00f3n.<\/p>\n\n\n\n

La decisi\u00f3n puede incluir aprobaci\u00f3n condicionada, soluci\u00f3n temporal, mitigaci\u00f3n obligatoria, limitaci\u00f3n operacional o necesidad de una nueva revisi\u00f3n.<\/p>\n\n\n\n\n

Las interfaces son puntos cl\u00e1sicos de conflicto de autoridad<\/h2>\n\n\n\n

A Gesti\u00f3n de Interfaces en Proyectos de Ingenier\u00eda<\/a> aborda los l\u00edmites entre sistemas, disciplinas, contratos y organizaciones. Es en esos l\u00edmites donde con frecuencia surge la pregunta: \u00bfqui\u00e9n tiene la decisi\u00f3n final?<\/p>\n\n\n\n

Una interfaz el\u00e9ctrica puede involucrar potencia disponible, protecci\u00f3n, selectividad, mando y automatizaci\u00f3n. Una interfaz civil-electromec\u00e1nica puede involucrar cargas, inserts, accesos y tolerancias. Una interfaz de telecomunicaciones puede involucrar protocolos, direccionamiento, sincronizaci\u00f3n y ciberseguridad.<\/p>\n\n\n\n

La matriz de interfaces deber\u00eda indicar no solo responsables de producir informaci\u00f3n, sino tambi\u00e9n la autoridad para resolver divergencias que superan la coordinaci\u00f3n rutinaria.<\/p>\n\n\n\n

La independencia debe ser suficiente para sostener una posici\u00f3n t\u00e9cnica<\/h2>\n\n\n\n

Una autoridad t\u00e9cnica incapaz de discrepar del equipo que controla su presupuesto, evaluaci\u00f3n o prioridad puede existir solo formalmente. La independencia no tiene por qu\u00e9 significar una organizaci\u00f3n separada en todos los casos, pero el dise\u00f1o debe reducir conflictos de inter\u00e9s incompatibles con la criticidad de la decisi\u00f3n.<\/p>\n\n\n\n

Cuanto mayor sea el riesgo t\u00e9cnico, m\u00e1s relevante es separar qui\u00e9n produce, qui\u00e9n revisa y qui\u00e9n autoriza. Esta l\u00f3gica tambi\u00e9n sustenta revisiones independientes, assurance y determinados stage-gates.<\/p>\n\n\n\n

Independencia, sin embargo, no significa ausencia de integraci\u00f3n. Technical Authority debe participar lo suficientemente temprano para que su actuaci\u00f3n no se limite a un veto tard\u00edo.<\/p>\n\n\n\n

\n

La independencia no es aislamiento: es la capacidad de sostener una conclusi\u00f3n t\u00e9cnica sin un conflicto de inter\u00e9s incompatible.<\/strong> Cuanto mayor sea la criticidad, m\u00e1s importante es separar producci\u00f3n, revisi\u00f3n, assurance y autoridad decisoria.<\/p>\n\n\n

Project Assurance en Ingenier\u00eda \u2192<\/strong><\/a><\/p>\n<\/div>\n\n\n\n\n

Los stage-gates deben explicitar qu\u00e9 decisiones son t\u00e9cnicas<\/h2>\n\n\n\n

Los gates de decisi\u00f3n son m\u00e1s robustos cuando distinguen autorizaci\u00f3n de negocio, autorizaci\u00f3n program\u00e1tica y aceptaci\u00f3n t\u00e9cnica. Un gate puede decidir si el proyecto debe continuar, pero esa decisi\u00f3n depende de evidencias que pueden exigir aprobaci\u00f3n t\u00e9cnica previa.<\/p>\n\n\n\n

Los criterios t\u00edpicos incluyen madurez de requisitos, resoluci\u00f3n de riesgos cr\u00edticos, integridad de interfaces, conclusi\u00f3n de Design Reviews, estado de desviaciones, readiness para contrataci\u00f3n, readiness para pruebas y cumplimiento de criterios de seguridad.<\/p>\n\n\n\n

A Gobernanza de Proyectos, Programas y Portafolios<\/a> debe definir estas autoridades sin transformar cada gate en una reuni\u00f3n excesivamente burocr\u00e1tica.<\/p>\n\n\n\n

La autoridad puede distribuirse por niveles de criticidad<\/h2>\n\n\n\n

Un modelo escalable evita que todas las decisiones lleguen a la m\u00e1xima autoridad. La organizaci\u00f3n puede establecer niveles para decisiones rutinarias, decisiones multidisciplinarias, cambios que afectan requisitos cr\u00edticos y excepciones de alta consecuencia.<\/p>\n\n\n\n

La clasificaci\u00f3n puede combinar consecuencia, reversibilidad, impacto sist\u00e9mico, exposici\u00f3n regulatoria e incertidumbre. El objetivo es mantener las decisiones simples cerca del equipo y elevar solamente aquello que realmente exige autoridad adicional.<\/p>\n\n\n\n

Las decisiones t\u00e9cnicas deben producir registros t\u00e9cnicos<\/h2>\n\n\n\n

Sin registro, la organizaci\u00f3n pierde la memoria de por qu\u00e9 se adopt\u00f3 determinada soluci\u00f3n. Technical Authority debe operar con artefactos proporcionales al riesgo: decision log, dictamen, technical query, deviation request, waiver, acta decisoria, aprobaci\u00f3n en workflow o registro en sistema de requisitos.<\/p>\n\n\n\n

El registro deber\u00eda preservar problema, opciones, criterios, evidencias, decisi\u00f3n, condiciones, responsables, fecha e impactos asociados.<\/p>\n\n\n\n

Esta disciplina conecta Technical Authority con la gesti\u00f3n documental, Engineering Change Management y la construcci\u00f3n de un historial utilizable en operaci\u00f3n, auditor\u00edas y proyectos futuros.<\/p>\n\n\n\n\n

Technical Authority participa en el cambio, pero no sustituye Change Control<\/h2>\n\n\n\n

Un cambio relevante puede exigir evaluaci\u00f3n t\u00e9cnica, comercial, contractual, financiera y de plazo. Technical Authority es responsable de la parte dentro de su autoridad, no de toda la decisi\u00f3n integrada.<\/p>\n\n\n\n

En Engineering Change Management<\/a>, la autoridad t\u00e9cnica debe aparecer en el flujo como aprobador o consultado seg\u00fan el tipo de cambio. Despu\u00e9s de la decisi\u00f3n, requisitos, documentos, modelos, interfaces, contratos y verificaciones deben actualizarse de manera consistente.<\/p>\n\n\n\n

Esta integraci\u00f3n impide que una aprobaci\u00f3n t\u00e9cnica se confunda con una autorizaci\u00f3n contractual o que una autorizaci\u00f3n comercial modifique silenciosamente la baseline t\u00e9cnica.<\/p>\n\n\n\n

Competencia y sucesi\u00f3n forman parte del modelo<\/h2>\n\n\n\n

Delegar autoridad exige criterios de competencia. Experiencia, formaci\u00f3n, conocimiento del activo, dominio normativo, capacidad de juicio e independencia son dimensiones m\u00e1s \u00fatiles que un t\u00edtulo jer\u00e1rquico aislado.<\/p>\n\n\n\n

La organizaci\u00f3n tambi\u00e9n necesita sucesi\u00f3n. Una funci\u00f3n cr\u00edtica dependiente de una sola persona crea riesgo operacional y puede paralizar aprobaciones. Una matriz de competencias, autoridades sustitutas y registros de delegaci\u00f3n reducen esa dependencia.<\/p>\n\n\n\n

La autoridad debe revisarse cuando cambian la funci\u00f3n, el proyecto, el riesgo, el alcance o la estructura organizacional.<\/p>\n\n\n\n

Technical Authority debe adaptarse a la escala de la organizaci\u00f3n<\/h2>\n\n\n\n

No toda empresa necesita una red formal equivalente a la de una agencia espacial. En una organizaci\u00f3n menor, el modelo puede ser una matriz de autoridades por disciplina y un procedimiento de escalamiento. En una cartera extensa de CAPEX, puede exigir autoridades por disciplina, sistema y nivel organizacional.<\/p>\n\n\n\n

El criterio es proporcionalidad: formalizaci\u00f3n suficiente para evitar ambig\u00fcedad decisoria sin crear una cadena que retrase decisiones simples.<\/p>\n\n\n\n

A Gesti\u00f3n de Ingenier\u00eda<\/a> proporciona el contexto m\u00e1s amplio en el que autoridades, requisitos, interfaces, assurance, PMO y controles deben funcionar como un sistema integrado.<\/p>\n\n\n\n\n

Se\u00f1ales de que una organizaci\u00f3n necesita formalizar la autoridad t\u00e9cnica<\/h2>\n\n\n\n

Algunos s\u00edntomas aparecen antes de un incidente: decisiones cr\u00edticas sin responsable claro, repetici\u00f3n de discusiones ya cerradas, desviaciones aprobadas sin trazabilidad, proveedores interpretando requisitos de maneras diferentes, conflictos recurrentes entre disciplinas, aprobaciones basadas \u00fanicamente en el cargo, ingenier\u00eda presionada para aceptar una soluci\u00f3n sin evaluaci\u00f3n registrada o cambios que no llegan a los documentos afectados.<\/p>\n\n\n\n

Otra se\u00f1al es la dependencia de personas espec\u00edficas para desbloquear cualquier cuesti\u00f3n t\u00e9cnica. Esto indica que la autoridad existe informalmente, pero no fue transformada en un proceso institucional.<\/p>\n\n\n\n

Formalizar significa transformar influencia dispersa en responsabilidad verificable.<\/p>\n\n\n\n\n

Una buena Technical Authority mejora la calidad de la decisi\u00f3n t\u00e9cnica<\/h2>\n\n\n\n

El resultado esperado no es producir m\u00e1s aprobaciones. Es garantizar que las decisiones relevantes se tomen en el nivel correcto, por personas competentes, con evidencias suficientes, l\u00edmites conocidos y posibilidad de escalamiento.<\/p>\n\n\n\n

Cuando esta estructura est\u00e1 integrada con la gobernanza, requisitos, interfaces, Design Review, Project Assurance y change control dejan de operar como mecanismos aislados. La organizaci\u00f3n pasa a tener una arquitectura expl\u00edcita para decidir, registrar, cuestionar y sostener posiciones t\u00e9cnicas a lo largo del ciclo de vida.<\/p>\n\n\n\n

Referencias t\u00e9cnicas<\/summary>\n

[1] NATIONAL AERONAUTICS AND SPACE ADMINISTRATION. Technical Authority<\/a>. Office of the Chief Engineer. Washington, DC: NASA.<\/p>\n\n\n\n

[2] NATIONAL AERONAUTICS AND SPACE ADMINISTRATION. NPR 7120.5F \u2014 NASA Space Flight Program and Project Management Requirements, Chapter 3: Technical Authority<\/a>. Washington, DC: NASA.<\/p>\n\n\n\n

[3] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 21505:2017 \u2014 Project, programme and portfolio management \u2014 Guidance on governance<\/a>. Geneva: ISO, 2017.<\/p>\n<\/details>\n\n\n\n

Preguntas frecuentes<\/summary>\n
\u00bfQu\u00e9 es Technical Authority en ingenier\u00eda?<\/strong>

Es una funci\u00f3n de gobernanza con autoridad t\u00e9cnica formalmente delegada para establecer, interpretar, mantener o aprobar requisitos, criterios, desviaciones y decisiones dentro de un dominio y una autoridad definidos.<\/p><\/div>

\u00bfTechnical Authority sustituye al gerente de proyecto?<\/strong>

No. El gerente de proyecto sigue siendo responsable de la entrega y de los compromisos del proyecto. Technical Authority protege decisiones y l\u00edmites t\u00e9cnicos espec\u00edficos dentro de la estructura de gobernanza.<\/p><\/div>

\u00bfCu\u00e1l es la diferencia entre Technical Authority y Project Assurance?<\/strong>

Project Assurance aporta una visi\u00f3n independiente sobre la salud y la confianza del proyecto. Technical Authority tiene mandato para tomar, aprobar o sostener determinadas decisiones t\u00e9cnicas.<\/p><\/div>

\u00bfTechnical Authority es lo mismo que Design Authority?<\/strong>

No necesariamente. Design Authority suele concentrarse en la integridad de la soluci\u00f3n o arquitectura de dise\u00f1o. Technical Authority puede tener un alcance m\u00e1s amplio sobre requisitos, est\u00e1ndares, disciplinas, sistemas, desviaciones y criterios t\u00e9cnicos.<\/p><\/div>

\u00bfCu\u00e1ndo necesita una empresa formalizar la autoridad t\u00e9cnica?<\/strong>

Cuando hay decisiones cr\u00edticas sin propietario claro, conflictos recurrentes entre disciplinas, desviaciones sin trazabilidad, alta criticidad t\u00e9cnica, m\u00faltiples proveedores o presi\u00f3n de plazo y costo que pueda comprometer requisitos y riesgos.<\/p><\/div>

\u00bfC\u00f3mo implementar Technical Authority sin burocratizar el proyecto?<\/strong>

Definiendo dominios, niveles de autoridad, criterios de criticidad, cadena de escalamiento y registros proporcionales al riesgo, manteniendo las decisiones rutinarias en el equipo y elevando \u00fanicamente excepciones relevantes.<\/p><\/div><\/div>\n<\/details>\n\n\n\n

Materiales t\u00e9cnicos complementarios<\/summary>\n

Soluciones relacionadas<\/strong><\/p>\n\n\n