9 ejemplos reales de RBAC
El control de acceso basado en roles (RBAC) es el modelo de gestión de acceso dominante en la TI empresarial. 94,7 % de las organizaciones han utilizado RBAC en algún momento, y el 86,6 % todavía lo considera su principal modelo de control de acceso a partir de 2026.1 Sin embargo, la mayoría del material publicado trata el RBAC como un marco teórico. Nos centramos en lo que realmente sucedió cuando organizaciones reales lo implementaron: los problemas específicos que enfrentaron, las configuraciones que eligieron y los resultados que midieron.
También cubrimos dónde el RBAC está llegando a sus límites, particularmente con la IA agéntica, los entornos multicloud y las obligaciones de cumplimiento cada vez más estrictas en virtud de las reglas HIPAA actualizadas y la Directiva NIS2 de la UE.
Ejemplos reales de RBAC
1. Dresdner Bank
Un importante banco europeo con 368 funciones laborales distintas y más de 1.300 roles organizativos llegó a un punto en el que su gestión de accesos se había convertido en un pasivo más que en un control.
Desafío: gestión manual de privilegios de acceso
El banco reestructuró su modelo de seguridad en torno a tres capacidades específicas del RBAC que antes le faltaban:
Agrupación demográfica y departamental: Antes del RBAC, los únicos ejes de clasificación eran el rol, la jerarquía y la unidad organizativa. El RBAC permitió al banco asignar permisos basándose en un conjunto más amplio de atributos sin crear un rol nuevo para cada combinación.
Herencia de roles: Este fue el cambio más trascendental. El banco no tenía una estructura de herencia, por lo que los cargos relacionados no tenían una relación implícita de permisos. Un gerente de finanzas no podía acceder a las notas contables mensuales sin pedirle al especialista contable que las recuperara. Tras implementar la herencia jerárquica de roles, el cargo del gerente de finanzas heredó automáticamente los permisos relevantes del especialista contable. La transferencia manual desapareció por completo.
Estructura de políticas centralizada: Sustituir los archivos de permisos a nivel de aplicación por una capa de política RBAC unificada dio a los administradores un único punto de revisión para las auditorías.
Por qué esto es importante para otras organizaciones: La experiencia del banco no es inusual. La proliferación de permisos a nivel de aplicación es común en organizaciones que hicieron crecer su pila de software más rápido que su modelo de gobernanza de accesos.
Ejemplo: Antes de implementar el RBAC, el gerente de finanzas tenía que pedirle al especialista contable que editara las notas contables mensuales. Ahora el gerente de finanzas accede directamente a las notas contables mensuales, ya que el cargo hereda el rol del especialista contable.2
2. Interfaith Medical Center
Organización educativa sanitaria comunitaria de múltiples centros con sede en EE. UU. con 50.659 empleados y 1.459 sucursales en todo el mundo.
Desafío: mantener el cumplimiento de HIPAA
HIPAA exige establecer controles internos basados en roles para los empleados a fin de proteger los datos electrónicos de salud de los pacientes contra un uso inadecuado.
Los administradores de Interfaith Medical Center tenían que configurar manualmente la base de datos para que solo los empleados autorizados (codificadores médicos, gestores sanitarios) tuvieran acceso a los datos de los pacientes.
Solución y resultado: Los administradores de TI utilizaron capacidades de gestión masiva para crear, eliminar y editar numerosas cuentas de Active Directory y establecer permisos de usuario específicos en una sola operación.
Gestión de accesos centralizada: Los administradores garantizaron que todo el acceso a la red se realice mediante un inicio de sesión único para cada empleado y no compartido.
Gestión automatizada del RBAC: Tras la implementación masiva del control de acceso basado en roles, la empresa afirma que puede gestionar con confianza 1.000+ objetos de usuario, 750+ buzones y 850+ estaciones de trabajo con dos administradores de bases de datos y cinco especialistas del servicio de asistencia. 3
Muchos hospitales ahora combinan el RBAC con acceso limitado en el tiempo. El cirujano obtiene acceso elevado solo durante la ventana programada de la operación y, luego, los permisos se revierten automáticamente.
Para las violaciones de HIPAA evaluadas a partir del 28 de enero de 2026, los máximos de sanción ajustados por inflación son ahora de $73,011 por violación para la mayoría de los niveles, con un tope anual de $2.190.294 para la negligencia intencional no corregida, frente a las cifras citadas anteriormente.4 Las organizaciones que citan tablas de multas HIPAA más antiguas en sus políticas internas deberían actualizarlas.
3. Western Union
Firma estadounidense internacional de servicios financieros con 5.000+ empleados con sede en Denver, Colorado.
Desafíos Operar un almacén de identidades centralizado: Los sistemas actuales de la empresa no les permitían extraer datos de origen de numerosas aplicaciones en el almacén de identidades, lo que daba como resultado una imagen poco clara de los controles de acceso de los usuarios. Cuando los gestores solicitaban la corrección de accesos, tenían que pasar por el sistema de tickets; sin embargo, el sistema no actualizaba eficazmente el perfil del usuario.
Administración de controles de acceso que consume mucho tiempo: El tiempo dedicado a administrar los controles de acceso y a reaccionar a los cambios normativos era largo. Cada nueva contratación requería acceso a entre 7 y 10 aplicaciones y los permisos relacionados. El acceso se suministraba manualmente y llevaba ~20 minutos por persona presentar la solicitud de acceso y recibir la aprobación de primer nivel.
La empresa esperaba ver quién tiene acceso a qué programas, servicios y archivos, y cómo evaluar si ese acceso cumple con la política de seguridad.
Solución y resultado: Western Union migró a una plataforma de gestión de identidades y accesos (IAM) con capacidades de RBAC para aproximadamente 750 aplicaciones.
Visibilidad de red mejorada con un almacén de identidades: Western Union comenzó a recopilar todos los datos de identidad basados en roles necesarios de los sistemas de RR. HH. en un único almacén de identidades, lo que permite una visibilidad completa de los privilegios de acceso de los usuarios en un entorno centralizado con 600+ aplicaciones.
Gestión robusta de la base de datos de usuarios: La empresa afirma que la solución de gestión de identidades basada en roles simplificó el procedimiento de aprovisionamiento para los departamentos que contratan nuevos empleados de forma habitual. Su aprovisionamiento de 50 usuarios ahora lleva 2.5 minutos, frente a los 14 minutos.5
Los bancos y las empresas de tecnología financiera ahora tratan el RBAC como parte de un modelo de confianza cero con auditoría continua.
4. Kubernetes en el sector sanitario
Habilitar el RBAC en Kubernetes y aplicarlo de verdad son dos cosas diferentes. Un relato de marzo de 2026 de un profesional sanitario que documenta una auditoría HIPAA real lo ilustra claramente.6
Qué ocurrió: El clúster superó la revisión documental. El RBAC estaba técnicamente habilitado. Pero la auditoría encontró:
- Tres espacios de nombres mal configurados
- Una cuenta de servicio con acceso de administrador del clúster que nadie del equipo recordaba haber creado
- Datos de pacientes moviéndose sin cifrar entre dos servicios internos
No se produjo ninguna brecha. Pero los tres hallazgos fueron fallos de auditoría, y cualquiera de ellos podría haber producido un incidente notificable.
El problema estructural: La regla de seguridad de HIPAA exige salvaguardas técnicas específicas, controles de acceso, pistas de auditoría, identificación única de usuarios, cifrado en tránsito y en reposo. El RBAC de Kubernetes cubre el requisito de control de acceso, pero no hace nada por el cifrado ni por la integridad de la pista de auditoría por sí solo. Los equipos que marcan “RBAC habilitado” en una lista de cumplimiento sin asignar cada salvaguarda técnica a una configuración específica del clúster no cumplen; solo están documentados.
Los clústeres de Kubernetes compatibles con HIPAA asignan el RBAC al estándar mínimo necesario: usuarios humanos vinculados a grupos del proveedor de identidades a través de OIDC/SSO con MFA, ClusterRoles reservados para tareas inevitables del plano de control, RoleBindings con ámbito de espacio de nombres como opción predeterminada y cuentas de servicio solo para cargas de trabajo.7
5. Plataformas en la nube: cómo AWS, Azure y Google Cloud estructuran el RBAC en la práctica
Los tres principales proveedores de nube implementan cada uno una variante del RBAC, pero las diferencias de arquitectura son importantes en la práctica.
AWS IAM
AWS IAM asigna permisos mediante políticas adjuntas a identidades (usuarios, grupos, roles) o recursos. Los roles son el mecanismo recomendado para el acceso entre servicios y entre cuentas. El control detallado está disponible a través de condiciones de política: hora del día, rango de IP y estado de MFA, lo que acerca AWS IAM al comportamiento basado en atributos manteniendo el RBAC como estructura organizativa.
Cómo funciona en la práctica: Un rol de desarrollador en una cuenta de producción puede tener acceso de solo lectura a S3 y CloudWatch, con acceso de escritura restringido a un rol de despliegue independiente que solo se asume durante la ejecución del pipeline de CI/CD. Separar el rol permanente del desarrollador de los permisos elevados de despliegue es la aplicación del mínimo privilegio dentro de las restricciones del RBAC.
Microsoft Entra ID + Azure RBAC
El RBAC de Azure se basa en una jerarquía de alcance de cuatro niveles. En la parte superior se encuentra el grupo de gestión, que abarca varias suscripciones y suele ser utilizado por las grandes empresas para aplicar políticas en todas las unidades de negocio. Por debajo está la suscripción, el límite principal de facturación y acceso para la mayoría de las organizaciones. Dentro de una suscripción se encuentran los grupos de recursos, contenedores lógicos para recursos relacionados como una aplicación web, su base de datos y su cuenta de almacenamiento. En la parte inferior de la jerarquía están los propios recursos individuales.
Defender for Cloud de Microsoft presentó Cloud Scopes y RBAC unificado, una capa única e independiente de la nube que segmenta los recursos y controla la visibilidad en AWS, Azure y GCP simultáneamente.8 Esto reemplaza el patrón anterior en el que las organizaciones que gestionan entornos de múltiples nubes tenían que mantener definiciones de roles independientes y no interoperables por proveedor. Para los equipos de seguridad que ejecutan entornos híbridos, este es un cambio operativo sustancial.
Google Cloud IAM
El IAM de Google Cloud se organiza en torno a una jerarquía de recursos de cuatro niveles. La organización se sitúa en la parte superior y se asigna a una cuenta de Google Workspace o Cloud Identity de la empresa. Es el nodo raíz al que, en última instancia, pertenecen todos los recursos. Debajo están las carpetas, que agrupan proyectos relacionados y suelen utilizarse para reflejar la estructura interna: unidades de negocio, equipos o entornos como producción y preproducción. Los proyectos se ubican dentro de las carpetas y actúan como el límite principal para la gestión de recursos, la facturación y el control de acceso. Los recursos individuales, las instancias de Compute Engine, los buckets de Cloud Storage y los datasets de BigQuery se sitúan en la parte inferior.
Los conjuntos de principales de cuentas de servicio permiten hacer referencia a todas las cuentas de servicio de un proyecto, carpeta u organización en políticas de permiso, denegación y acceso, lo que resulta útil para organizaciones que gestionan grandes poblaciones de cuentas de servicio. La autoconsesión de permisos faltantes a partir de los mensajes de error (disponibilidad general el 27 de febrero de 2026) reduce la fricción de la depuración de permisos.9
En Google Cloud Next ’26, Google también anunció un catálogo optimizado de roles predefinidos con roles simplificados de administrador, editor y lector, un selector de roles de IAM y la capacidad de exigir una nueva autenticación para acciones sensibles.10
6. VLI
Proveedor de logística ferroviaria en Brasil. Gestiona el sistema ferroviario, 100 locomotoras, más de 6.000 vehículos ferroviarios, con 8.000 empleados y 1.000 contratistas.
Desafío: controles de acceso complejos en la cadena de suministro: La empresa tenía dificultades para asignar acceso a los registros del movimiento de mercancías y las transacciones.
CISO de VLI: “Tenemos ~9.000 empleados que necesitan usar varios sistemas para mover trenes, y necesitamos un sistema gobernado para una mejor sincronización; los empleados no pueden esperar para tener acceso y descargar el camión.”
Los conductores de camiones y los operadores de trenes tenían que iniciar sesión continuamente en los sistemas para obtener información y realizar transacciones como parte de su rutina de carga, lo que ralentizaba el proceso y reducía la productividad. A pesar de la presencia de amplios equipos de TI y desarrollo, no existía ningún mecanismo para detectar o rastrear a las personas privilegiadas que accedían a los servidores de VLI.11
Solución y resultado: VLI migró a una plataforma centralizada de control de acceso de usuarios.
Gestión rápida del acceso de usuarios: VLI alcanzó la capacidad de dar a los usuarios adecuados acceso a los recursos relevantes en el momento adecuado. Redujo los tiempos de respuesta de las solicitudes de acceso de los usuarios de 5 días a segundos.
Servidores protegidos: Protegieron los servidores eliminando el requisito de compartir información de inicio de sesión autorizada.
Riesgo reducido de ataques de malware y ransomware: Limitaron el número de usuarios no administradores con acceso administrativo en los endpoints y establecieron listas de aplicaciones fiables y no fiables e instrucciones, minimizando el riesgo de ciberataques.
7. Nine Entertainment
La mayor empresa de medios de comunicación de propiedad nacional de Australia.
Desafío: permisos de control de acceso: El mantenimiento de soluciones a medida se convirtió en una carga enorme para el personal técnico, ya que no lograban gestionar miles de permisos de control de acceso.
Solución y resultado: Nine Entertainment creó un directorio unificado con sincronización de AD en tiempo real y MFA para construir procedimientos RBAC estandarizados.12
Gestión de accesos unificada: La empresa utiliza eficazmente 200+ conexiones para dar acceso a 50+ aplicaciones y a múltiples sitios de WordPress basados en permisos personalizados.
Controles de autenticación mejorados: Con la implementación del software, los usuarios de Nine Entertainment ya no necesitan introducir códigos MFA; la autenticación se produce sin problemas.
Ejemplo: Con funciones de gestión de identidades y RBAC, Nine Entertainment podía detectar a los usuarios que iniciaban sesión desde cualquier ubicación, como la oficina en casa. Si el usuario necesita inscribirse con autenticación basada en la identidad, se le guía mediante un procedimiento de inscripción de autoservicio basado en un asistente.
8. SaaS y aplicaciones multiinquilino: el problema de la explosión de roles
Las plataformas de soporte al cliente, las herramientas de gestión de proyectos y los CRM SaaS representan un desafío distinto para el RBAC.
Esto es manejable con cuatro roles. El problema surge cuando los equipos empiezan a dar cabida a excepciones.
Se trata de una explosión de roles. Es un modo de fallo estructural del RBAC, no un caso límite. Ocurre específicamente cuando las organizaciones intentan codificar variaciones de políticas, condiciones, excepciones y contexto en los nombres de los roles en lugar de en un motor de políticas diseñado para manejarlos.
Cómo lo abordan las organizaciones:
La solución práctica es un modelo híbrido. El RBAC gestiona los roles básicos de función laboral que son estables y están bien definidos. ABAC (control de acceso basado en atributos) o PBAC (control de acceso basado en políticas) gestiona las condiciones: hora de acceso, estado del dispositivo, nivel de clasificación de datos y ubicación geográfica.
9. RBAC e IA agéntica: el problema estructural de 2026
El RBAC tradicional se diseñó para usuarios humanos con identidades estables y patrones de acceso predecibles. Los agentes de IA no son ninguna de las dos cosas.
En RSAC 2026, el CEO de Oasis Security, Danny Brickman, describió el problema central: “Un agente es tan bueno como el acceso que se le concede. Un agente sin acceso básicamente no significa nada. Un agente con acceso total a los datos de su empresa tiene todo el valor potencial que se da a la organización.”13
El problema no es simplemente que los agentes de IA necesiten roles. Es que operan de manera diferente a los usuarios humanos, rompiendo los supuestos centrales del RBAC:
- Las identidades de máquina ya superan con creces a las humanas en la mayoría de los entornos empresariales
- Los agentes cambian de estado dinámicamente. El mismo agente que maneja tareas rutinarias en un momento puede necesitar acceso escalado al siguiente
- Un agente que hereda los permisos completos de un usuario (común en las primeras implementaciones) crea un exceso de privilegios heredado a escala
- El registro de auditoría muestra la identidad del agente, no la del usuario de origen, rompiendo la rendición de cuentas
IANS Research identificó las soluciones de Model Context Protocol (MCP) como el patrón de integración específico en el que las estructuras actuales de autenticación y autorización están creando una exposición real.14
La respuesta de la industria avanza hacia modelos de acceso basados en la intención y justo a tiempo: permisos temporales de alcance limitado, aprovisionados cuando se necesitan y revocados automáticamente, en lugar de roles permanentes que un agente mantiene de forma continua.15
¿Qué es el RBAC?
El control de acceso basado en roles (RBAC) es un modelo para gestionar el acceso de los usuarios con el fin de proteger recursos como información, aplicaciones y sistemas contra accesos no autorizados.
Figura 1: Asignaciones de roles del control de acceso basado en roles
Problemas sin RBAC
Aplicar el principio del “mínimo privilegio” es difícil: los administradores no pueden comprender los roles y permisos de los usuarios. Podrían no identificar el grado más bajo de acceso que un empleado necesita para realizar sus tareas.
La incorporación lleva más tiempo: Los permisos de los nuevos empleados se presentan caso por caso mediante formularios específicos.
Los cambios de puesto son complejos: controlar el acceso de las personas que cambian de trabajo requiere solicitudes de ajuste individualizadas.
Riesgo de acceso no autorizado: Puede implicar un uso indebido, provocando accesos duplicados (el acceso de Bert aparece como el de Eva).
Demostración del RBAC: asignación de roles y permisos
Pensemos en una clínica dental que se suscribe a un producto SaaS para administrar y promocionar servicios de salud a clientes potenciales con los siguientes módulos:
Módulo de facturación: Cobra los pagos de las compañías de seguros y de los pacientes por los servicios médicos cubiertos por los códigos de facturación dental.
Módulo de ventas: Permite a las clínicas dentales clasificar a los posibles clientes potenciales según la probabilidad de comprar un producto o servicio.
Configuración de permisos
Los administradores de la clínica dental utilizan la interfaz de usuario del software para asignar permisos de acceso a diversas funciones empresariales.
Mediante opciones de arrastrar y soltar, los administradores crean diferentes permisos: “ver”, “editar”, “crear” y “eliminar”.
Permisos del módulo de facturación (solo gestor de facturación):
- ver: billing_codes
- ver: customer_ID
- crear: invoice
Permisos del módulo de ventas (gestor de ventas):
- ver: sales_database
- crear: sales_database
- editar: sales_database
- eliminar: sales_database
Después de configurar los permisos, el administrador crea el rol de “gestor de ventas” y asigna estos permisos a ese rol, limitando el acceso de otros empleados a la base de datos de ventas.
Figura 2: Evaluación de las políticas RBAC para el “sales_manager” con elementos de la interfaz de usuario (UI)
Figura 3: Ejemplo de cómo podría verse el archivo data.json para los roles “billing_manager” y “sales_manager”:
5 beneficios del RBAC
1. Acceso excesivo limitado
Con la transición a la infraestructura en la nube, las aplicaciones SaaS y el inicio de sesión único (SSO), las personas y los grupos heredan con frecuencia roles con acceso excesivo. El RBAC reduce este riesgo al definir grupos y subgrupos para que los usuarios tengan acceso solo a lo que necesitan.
Ejemplo: Los usuarios envían imágenes a un concurso para las mejores fotos de viajes. Solo los jueces del concurso deberían ver esas fotos. La política permite a cualquier entrada en la posición “travel_photo_judges” examinar la foto “travel_photo1997.jpg”.
Esto se logra mediante la evaluación del RBAC, que pasa la información del grupo al motor de evaluación y determina si la entrada indicada en la solicitud de permiso es miembro del grupo.
2. Políticas de control de acceso únicas
Los sistemas RBAC proporcionan políticas de control de acceso más granulares adaptadas a las necesidades de una empresa que los sistemas mainframe.
Ejemplo: Los administradores de sistemas RBAC emplean roles con fines administrativos restringiendo el acceso a la red en función del rol de una persona, como “usuario invitado con permisos limitados”.
3. Soporte a nivel de aplicación
El RBAC ayuda a las empresas a tener un enfoque de acceso granular al admitir permisos a nivel de aplicación.
Ejemplo: El RBAC puede asignar un conjunto de permisos en un programa de escritura que permite a los usuarios leer, editar y eliminar contenido.
4. Asignación flexible de roles
Los modelos RBAC construyen relaciones entre roles, permisos y usuarios. Dos roles pueden ser mutuamente excluyentes, lo que permite a un solo usuario tener dos roles. Los roles pueden heredar permisos proporcionados a otros roles.
Ejemplo: Cuando se establece un permiso, puede asignarse a numerosos roles. Matt puede tener roles de especialista administrativo y financiero, mientras que Eva puede tener solo un rol de especialista financiero.
5. Demostración del cumplimiento
Implementar el RBAC ayuda a las instituciones financieras y a los proveedores de atención médica a demostrar el cumplimiento de las normas técnicas y operativas, incluidas HIPAA, PCI y PHI.
¿Por qué usar RBAC?
El acceso no autorizado a la red representó el 40 % de las intrusiones cibernéticas de terceros en 2023. Teniendo en cuenta que el acceso no autorizado es uno de los principales impulsores de las violaciones de datos, establecer el RBAC es fundamental, especialmente para empresas con varios empleados.
1. Seguridad mejorada
Riesgo minimizado de acceso no autorizado: Al asignar permisos por roles en lugar de por individuos, es más fácil garantizar que los usuarios solo tengan acceso a la información y los recursos necesarios para sus roles.
Aplicar el principio del mínimo privilegio: A los usuarios se les concede el nivel mínimo de acceso necesario para realizar su trabajo, lo que reduce el riesgo de violaciones internas de datos y de exposición a información confidencial.
2. Gestión simplificada
Facilidad de administración: Los administradores pueden asignar y gestionar fácilmente los permisos de los usuarios por rol en lugar de gestionarlos de forma individual.
Escalabilidad: A medida que las organizaciones crecen, los nuevos usuarios se asignan rápidamente a roles predefinidos, lo que agiliza el proceso de incorporación y garantiza políticas de control de acceso coherentes.
3. Riesgo reducido de errores
Control centralizado: La gestión centralizada de roles reduce el riesgo de error humano al asignar permisos y garantiza que las políticas de acceso se apliquen de forma coherente.
Responsabilidad clara: Con el RBAC es más fácil determinar la responsabilidad y la rendición de cuentas por el acceso a recursos sensibles.
4. Cumplimiento normativo
Cumplimiento normativo: El RBAC ayuda a las organizaciones a cumplir diversos requisitos normativos al garantizar que el acceso a los datos sensibles esté controlado y documentado.
Pistas de auditoría: La naturaleza basada en roles del control de acceso facilita el seguimiento y la auditoría de quién tiene acceso a qué recursos, lo que permite una mejor supervisión y elaboración de informes.
Añadir como fuente preferidaFuturo del RBAC
En todos los sectores, el RBAC ha pasado de:
Cargos estáticos: roles dinámicos basados en tareas
Permisos permanentes: acceso temporal y contextual
Control solo humano: gobernanza de identidades humanas y de IA
El RBAC ya no se trata solo de “quién puede iniciar sesión”. Se trata de quién puede actuar, cuándo y bajo qué condiciones, con cada acción trazable.
Lecturas adicionales
- Las 10 mejores herramientas de microsegmentación
- Prevención de intrusiones: ¿cómo funciona? y 3 métodos
- Soluciones de gestión de políticas de seguridad de red (NSPM)
Cita esta investigación
Elige el formato que se ajuste al lugar donde vas a publicar. Pegar la versión con enlace en tu CMS conserva el enlace de retroceso.
@misc{dilmegani2026,
author = {Dilmegani, Cem},
title = {{9 ejemplos reales de RBAC}},
year = {2026},
month = may,
howpublished = {\url{https://aimultiple.com/rbac-examples}},
note = {AIMultiple. Recuperado el 26 de mayo de 2026}
}Registro de cambios
4 actualizacionesAñadidas secciones sobre RBAC de Kubernetes en sanidad, RBAC de proveedores en AWS, Azure y Google Cloud, e IA agéntica.
Se amplió la sección "Ejemplos reales de RBAC" con tres nuevos ejemplos de empresas.
Enlaces de referencia
El trabajo de Cem en AIMultiple ha sido citado por publicaciones líderes mundiales como Business Insider, Forbes, Morning Brew y Washington Post, empresas globales como Deloitte y HPE, ONG como World Economic Forum y organizaciones supranacionales como European Commission. [1], [2], [3], [4], [5]
A lo largo de su carrera, Cem trabajó como consultor tecnológico, comprador de tecnología y emprendedor tecnológico. Asesoró a empresas en sus decisiones tecnológicas en McKinsey & Company y Altman Solon durante más de una década. También publicó un informe de McKinsey sobre digitalización.
Dirigió la estrategia tecnológica y las adquisiciones de una empresa de telecomunicaciones reportando al CEO. También lideró el crecimiento comercial de la empresa de deep tech Hypatos, que alcanzó unos ingresos recurrentes anuales de 7 dígitos y una valoración de 9 dígitos desde 0 en 2 años. El trabajo de Cem en Hypatos fue cubierto por publicaciones tecnológicas líderes como TechCrunch y Business Insider.
Cem participa habitualmente en conferencias internacionales de tecnología. Se graduó en Bogazici University como ingeniero informático y tiene un MBA de Columbia Business School.
Sé el primero en comentar
Tu dirección de correo electrónico no será publicada. Todos los campos son obligatorios. Los comentarios se dejan en su idioma original.