Por qué la infraestructura determina el éxito o el fracaso
Seguro que le suena: El CEO vuelve entusiasmado de la última presentación sobre IA. “¡Necesitamos un chatbot como ese!” es el siguiente mensaje. El departamento de marketing sueña con la generación automática de contenidos. ¿Y usted, como responsable de IT? La pregunta clave es: “¿Eso funcionará realmente de forma fiable en nuestra infraestructura actual?”
Una objeción muy legítima. Porque, aunque el uso estándar de herramientas como ChatGPT o Microsoft Copilot suele ser sencillo, la situación se complica rápidamente cuando se trata de soluciones de IA a medida. ¿El obstáculo? Casi siempre, la infraestructura de IT existente.
La razón es fácil de explicar: las aplicaciones de IA plantean requisitos muy diferentes a los de los sistemas de software tradicionales. Mientras un sistema ERP gestiona transacciones estructuradas, un sistema de IA opera con enormes volúmenes de datos no estructurados, a menudo en casi tiempo real.
Para dejarlo aún más claro: La infraestructura IT consolidada, que hasta ahora funcionaba a la perfección, a menudo alcanza sus límites ante cargas de trabajo de IA. No se trata de una mala arquitectura, sino de que aquí se aplican otras reglas del juego.
Según un estudio reciente de Bitkom (2024), dos tercios de las empresas encuestadas —en el mid-market incluso más del 70 %— afirman que la falta de requisitos técnicos retrasa o bloquea sus proyectos de IA. No debe sorprender si observamos las demandas del sector.
¿Pero qué es tan diferente? Básicamente, hay tres factores que su infraestructura debe cumplir para estar lista para la IA:
Intensidad de cálculo: Los modelos modernos de IA requieren una enorme potencia de cómputo en paralelo. Los servidores optimizados para CPU llegan rápido a límites físicos.
Hambre de datos: Cuantos más datos, mejor aprende el sistema de IA. Esto exige canales de almacenamiento y transferencia muy por encima de los requerimientos clásicos de bases de datos.
Requisitos en tiempo real: Quienes usan la IA esperan respuestas en segundos o incluso al instante. Una latencia elevada es como arena en el engranaje: molesta y poco eficiente.
La buena noticia: no es necesario renovar toda la infraestructura. Con una mirada centrada en los requisitos reales y algunos ajustes específicos, su sistema actual puede dar mucho más de sí en IA de lo que imagina.
Los cuatro pilares de una infraestructura IT preparada para IA
Una infraestructura de IA robusta se sostiene sobre cuatro pilares. Cada uno es esencial —si uno falla, puede convertirse rápidamente en un cuello de botella. Veamos los detalles:
Potencia de cálculo y requisitos de hardware
A diferencia del software tradicional, las cargas de trabajo de IA están enormemente paralelizadas. Mientras que su contabilidad procesa registro por registro, los algoritmos de Machine Learning lanzan miles de cálculos al mismo tiempo.
Por eso las tarjetas gráficas (GPU) se hacen imprescindibles. Empresas como NVIDIA marcan el estándar con modelos como la A100, H100 o la serie RTX. Una sola NVIDIA A100 ofrece una capacidad de computación comparable a lo que antes necesitaba racks completos de servidores.
Pero ojo: ¡No todas las GPU son iguales! Para la inferencia de modelos suelen bastar GPUs de entrada (como la NVIDIA T4), mientras que para entrenar grandes modelos propios las tarjetas de gama alta como la H100 son generalmente inevitables. Las soluciones Edge como Google Coral TPU o Intel Movidius destacan por su eficiencia para usos descentralizados.
¿Y la RAM? Los modelos grandes exigen lo suyo: Un LLM local como Llama 2 en su variante de 70.000 millones de parámetros requiere al menos 140 GB de RAM, sin contar el procesamiento de texto.
El procesador (CPU) sigue siendo el motor para la pre y post-procesamiento de datos, así como la gestión del sistema. En IA se recomiendan especialmente CPUs con muchos núcleos y amplios carriles PCIe, como AMD EPYC o Intel Xeon Scalable.
Arquitectura de datos y sistemas de almacenamiento
La IA es voraz en datos —y de una forma muy peculiar. Un ERP tradicional almacena tablas estructuradas; los modelos de IA consumen cualquier información: texto, imágenes, audio, vídeo.
Esto exige arquitecturas de almacenamiento más flexibles. El Object Storage (como Amazon S3 o Azure Blob) se ha convertido en el nuevo estándar. Para el entorno On-Premise, MinIO es una opción popular. Lo clave: arquitectura prácticamente ilimitada y preparada para crecimientos explosivos.
También importa la velocidad: las SSDs NVMe modernas ofrecen grandes velocidades, pero suelen quedarse cortas en el entrenamiento masivo. Sistemas de ficheros distribuidos como Ceph o GlusterFS agrupan recursos a través de múltiples discos y servidores, multiplicando así la capacidad de cálculo en paralelo para IA.
¿Ejemplo real? Una empresa industrial con un proyecto de mantenimiento predictivo genera terabytes de datos de sensores. Las soluciones tradicionales flaquean cuando se requieren accesos rápidos y grandes volúmenes. La arquitectura de objetos y sistemas distribuidos evita esos cuellos de botella.
Crucial también es el preprocesamiento de datos. Mediante pipelines ETL (Extract, Transform, Load) los datos se preparan para la IA —Apache Kafka es la elección habitual para escenarios de streaming, y Elasticsearch agiliza la búsqueda e indexado de grandes volúmenes.
Una regla básica de IA nunca pasa de moda: “Garbage in, garbage out”. Implemente estándares de calidad, mediante Data Governance o rutinas automáticas de control. Toda solución de IA es tan buena como los datos de entrada.
Red y conectividad
El viejo paradigma servidor-usuario ya no basta en el mundo de la IA. Cualquier aplicación de IA en tiempo real —chatbots, análisis documental— desafía su red.
¿Un ejemplo? Un sistema RAG (Retrieval Augmented Generation) rastrea millones de documentos en cada solicitud del usuario. Si el almacenamiento es NAS o distribuido, las redes tradicionales se colapsan rápidamente.
Por eso, las infraestructuras modernas de IA apuestan por Ethernet de al menos 10 gigabits, a menudo mucho más (25GbE hasta 100GbE). InfiniBand sigue siendo el estándar en alto rendimiento, aunque no es viable para todos los presupuestos o usos.
En interacciones avanzadas, cada milisegundo de latencia cuenta. Switches modernos y cableado redundante (por ejemplo, con LACP) son imprescindibles, así como un monitoreo constante. ¿Equipos geográficamente distribuidos? Considere servidores Edge, que reducen latencia y ahorran ancho de banda WAN.
La estabilidad y el rendimiento aumentan almacenando datos relevantes localmente (Edge Computing) y planificando la estructura de red para máxima tolerancia a fallos. Clave: la redundancia no es sólo “un extra”, sino una obligación en proyectos de IA.
Seguridad y cumplimiento normativo
La IA aumenta la superficie de ataque. Muchos de los casos de uso más interesantes involucran datos personales o se integran en procesos de negocio —por tanto, la seguridad pasa a ser clave.
El GDPR exige decisiones explicables —por lo que las IA de caja negra generan críticas, especialmente en sectores regulados. Debe asegurarse el uso de modelos explicables (“Explainable AI”), o al menos, contar con documentación y capacidades de auditoría.
Un vector de ataque moderno: la manipulación de datos de entrenamiento (Model Poisoning), que puede llevar a errores graves. Proteja los datos mediante controles de acceso y monitorice todos los flujos de datos.
No pueden faltar el cifrado “en reposo” y “en tránsito”. Los módulos de seguridad hardware (HSM) ya son estándar en muchos data centers. Las GPUs de IA modernas incluyen funciones como “Confidential Computing” para proteger los datos más sensibles.
Zero Trust no es sólo una moda: limite al mínimo los accesos, separe datos de producción y servicios de IA y controle de forma granular cada flujo de datos. Orquestadores de contenedores (Kubernetes) y políticas de red pueden ayudar con esto.
La formación continua en seguridad es la sal de la vida: archivos adjuntos falsos o ataques dirigidos a la infraestructura siguen siendo la vía de entrada más común —palabra clave: ingeniería social.
Casos de uso de IA y sus requisitos específicos
No existe “la aplicación” de IA. Cada caso de uso implica distintos requerimientos de infraestructura. Analicemos juntos los escenarios más relevantes para medianas empresas y las claves a tener en cuenta:
Chatbots y Conversational AI
Para muchos, los chatbots son la puerta de entrada al mundo de la IA —parecen simples, pero su complejidad interna es considerable. El cuello de botella habitual: la latencia. Los usuarios esperan respuestas inmediatas, y cada segundo extra hace perder confianza.
Un estudio de Google demuestra que los tiempos de carga de más de 3 segundos llevan al abandono de la web —en el caso de chatbots, incluso pequeños retrasos implican menos clics.
(Nota: El estudio de Google se refiere a la carga de páginas web y no a los tiempos de respuesta de chatbots, pero la analogía es útil.)
Para bots de FAQ sencillos a menudo bastan CPUs modernas. Herramientas como BERT o DistilBERT funcionan bien en instancias cloud o servidores potentes —por ejemplo, Azure D4s_v3 es suficiente para necesidades medias.
Para IA conversacional más compleja —por ejemplo, con modelos grandes como GPT-4— las GPUs como NVIDIA T4 o superiores son imprescindibles. Una sola tarjeta puede gestionar decenas de conversaciones en paralelo, según el modelo y la longitud del contexto.
La escalabilidad es a menudo subestimada: Un bot que pasa de 10 a 200 chats simultáneos puede sorprender a la infraestructura. El autoescalado con Kubernetes o soluciones similares es un must, y el rate limiting protege a los sistemas backend.
Un clásico igualmente importante es la gestión de sesiones. Hay que guardar el contexto: Redis o almacenes en memoria similares permiten accesos rápidos. El problema: la pérdida de historial de chat acaba en frustración y llamadas al soporte.
Sistemas RAG (Retrieval Augmented Generation)
¿Qué es un RAG exactamente? Retrieval Augmented Generation combina grandes modelos lingüísticos con el conocimiento corporativo propio. La arquitectura es más compleja que la de un simple chatbot: primero, un motor de recuperación localiza documentos relevantes y después el LLM genera la respuesta basada en esos datos.
Pieza clave: una base de datos de vectores (por ejemplo Pinecone, Weaviate, Qdrant) que almacena fragmentos de texto como “embeddings” —representaciones vectoriales comprimidas. Un millón de embeddings ya necesitan unos 5GB de espacio, y con datos grandes es mucho más.
Generar esos embeddings requiere bastante potencia, normalmente con soporte de GPU. En producción, la base de datos debe buscar millones de vectores en milisegundos —algoritmos como HNSW o IVF ofrecen el rendimiento necesario.
Ejemplo práctico: una empresa industrial que carga miles de documentos técnicos para su base de conocimiento. Sin una arquitectura de búsqueda optimizada, contestar preguntas puede tardar 5 segundos; con una base de datos vectorial ajustada, está en menos de 200 ms.
¿Sus documentos cambian constantemente? Los procesos ETL automáticos para actualizar los vectores son indispensables —ideales si permiten actualizaciones parciales rápidas en vez de reindexar todo el archivo.
Otro punto a considerar son los Context Window Limits de los modelos lingüísticos. GPT-4, por ejemplo, procesa como máximo 128.000 tokens a la vez; para grandes estructuras documentales debe implementarse un chunking y resúmenes inteligentes.
Su objetivo: velocidad y actualidad no deben ser excluyentes. Sistemas de caché mejoran el rendimiento y reducen los costes —Redis también es útil aquí.
Procesamiento de documentos y OCR
La empresa sin papel no se logra solo digitalizando archivos, sino mediante procesamiento inteligente de documentos con IA. Los sistemas modernos de OCR (Reconocimiento Óptico de Caracteres) combinan un excelente reconocimiento de texto con compresión estructural: tablas, formularios y firmas son leídas automáticamente.
La clave: los modelos de Computer Vision necesitan gran potencia de GPU. Un escaneo estándar a 300 DPI puede tener varios megapíxeles, y aquí las tarjetas básicas no son suficientes.
Piense en cargas de trabajo: el procesamiento en batch (por ejemplo, albaranes por la noche) se gestiona mejor con GPUs estándar; los análisis en tiempo real para clientes exigen modelos de gama alta.
Consejo: Una buena OCR solo es tan buena como su pre-procesamiento. Inclinaciones, sombras o mala iluminación se corrigen con pipelines basadas en OpenCV. Modelos como LayoutLM analizan la estructura y contexto en el documento —pero exigen hardware potente.
El almacenamiento es importante: Para guardar originales y extractos, lo mejor es Object Storage con rutinas automáticas de archivado y borrado. Para empresas sujetas al GDPR, los trazados de auditoría y la gestión de datos son imprescindibles.
Analítica predictiva e inteligencia empresarial
La analítica predictiva convierte los datos de ayer en decisiones de hoy, desde previsiones de ventas hasta mantenimiento predictivo. Muy habituales: modelos LSTM o Transformer para series temporales. Su entrenamiento rara vez se completa en horas; semanas de entrenamiento son habituales según el volumen de datos.
Claves: Feature Engineering —identificar y preparar las variables correctas para los modelos. La paralelización marca la diferencia: con Apache Spark también grandes volúmenes se procesan ágilmente.
La inferencia en tiempo real —por ejemplo, con datos bursátiles— requiere latencias por debajo de 10 ms, y no cualquier sistema lo consigue de serie. Aquí se necesita una infraestructura específica y buen conocimiento de los procesos que se automatizarán.
Ejemplo: una empresa logística usa analítica predictiva para su planificación ambiental y de rutas. El entrenamiento de nuevos modelos puede completarse en hardware potente en unas horas; la explotación debe estar paso a latencia optimizada.
Importante: los modelos pierden precisión con el tiempo si los datos cambian (“Model Drift”). El monitoreo y el retraining periódico no son opcionales, sino obligatorios. Las IA explicables—como SHAP o LIME—aportan transparencia pero requieren recursos adicionales.
Cloud vs. On-Premise: Tomar la decisión correcta
Para muchas empresas es la gran pregunta: ¿Nube o infraestructura propia? Hay defensores y argumentos para ambos lados. Lo importante es el caso de uso concreto y el apetito por el riesgo.
Punto para la nube: permite escalar de forma flexible, pagar solo por uso y acceder a hardware moderno sin gran inversión inicial. AWS, Azure y otros ofrecen instancias GPU desde unos pocos euros por hora, ideal para pruebas y pilotos.
Pero cuidado con los costes: la operación continua en la nube puede salir muy cara. Una instancia GPU potente puede costar tanto al mes como la compra de un servidor nuevo —con grandes cargas permanentes, On-Premise a menudo resulta rentable pasado cierto umbral.
Latenica y protección de datos también pesan: De poco sirve la mejor instancia GPU si los datos están en servidores de otro país, o si normas como el GDPR prohíben llevar datos sensibles al extranjero. Por eso es clave comprobar disponibilidad y escenarios de compliance desde el principio.
Las soluciones híbridas son flexibles: las aplicaciones sensibles corren en local, y los picos de carga se derivan dinámicamente a la nube (“Cloud Bursting”). Eso sí, la orquestación y el monitoreo se hacen más complejos.
Edge Computing lleva la IA directamente allí donde se genera el dato —en las instalaciones de la empresa o cerca del cliente. Así se reduce la latencia y se refuerza la seguridad. Para algunas empresas, el Edge es la verdadera joya escondida.
¿Busca el máximo control y previsibilidad? On-Premise sigue siendo la opción preferida: incluye costes de energía, mantenimiento y gestión del hardware. Las soluciones modernas apuestan por la contenerización, facilitando así cambios entre la nube y sistemas propios.
Integración en sistemas legacy existentes
El gran escollo en muchos proyectos de IA es la integración con sistemas antiguos. Su IA puede ser puntera, pero sin datos de sus sistemas ERP, MES o similares, se queda en papel mojado.
El problema: muchas aplicaciones legacy no ofrecen APIs modernas. Los datos están en bases históricas. Acceder a ellos sin interrumpir el negocio es cuestión de finesse.
Las ETL-Pipelines (por ejemplo, con Apache Airflow) han demostrado su valor al extraer datos necesarios de forma periódica y controlada. Réplicas de bases de datos en modo sólo lectura protegen los sistemas productivos, y herramientas como Apache Kafka facilitan la comunicación asíncrona entre lo viejo y lo nuevo.
Consejo práctico: Use interfaces bien definidas y apueste por pasos de modernización graduales —microservicios en lugar de grandes migraciones. El Change Data Capture (CDC) permite llevar en tiempo real los cambios a los nuevos sistemas, incluso con bases de datos antiguas.
El almacenamiento temporal de datos muy solicitados en Redis o Memcached alivia la carga sobre los sistemas antiguos. El monitoreo y los mecanismos de rollback son imprescindibles: ni pymes ni grandes empresas quieren sorpresas ni caídas.
Y no olvide: ¡Muchos sistemas legacy son fábricas de datos heterogéneos! Hay que comprobar calidad y estructura en el preprocesamiento, o la IA será ineficaz.
Escalado y optimización del rendimiento
Asegurar el éxito de un proyecto de IA implica también planificar su crecimiento. Los retos aquí son específicos: la escalabilidad a nivel GPU difiere de la de los servidores web tradicionales.
El escalado horizontal —muchas instancias pequeñas en vez de pocas grandes— funciona de serie con CPUs, pero con GPUs es más complejo y costoso: no siempre hay instancias disponibles, los tiempos de arranque ralentizan y compartir recursos en una GPU es delicado.
Kubernetes y otras herramientas de orquestación ayudan gestionando los nodos GPU como pools dedicados. Los autoescaladores gestionan la dinámica y la tecnología Multi-Instance GPU de NVIDIA facilita la isolación de recursos.
Un buen Model Serving es la base del rendimiento. Cargar modelos previamente en servicios sin estado potencia la escalabilidad. TensorFlow Serving y TorchServe son opciones establecidas para muchas empresas.
Fundamentales son las estrategias inteligentes de caching y balanceo de carga: el Round-Robin simple rara vez basta; el enrutamiento basado en tiempos de respuesta distribuye mejor los trabajos.
Los lotes y servicios en tiempo real exigen optimizaciones distintas; mantenga claro el modelo operativo al menos al principio. La cuantización de modelos (8/16 bits en lugar de 32) reduce necesidades de memoria y latencia.
En resumen: monitorice constantemente el uso de GPU, accuracy del modelo y consumo de memoria con herramientas como Prometheus y Grafana. Los circuit breakers previenen efectos dominó por sobrecarga y el edge caching acerca las respuestas de IA al usuario, reduciendo aún más la latencia.
Análisis de coste-beneficio y planificación presupuestaria
Quien planifica un proyecto de IA debe pensar no solo en lo posible, sino en lo viable económicamente. En la práctica, incluso pequeños proyectos pueden alcanzar seis cifras rápidamente —sobre todo cuando entran servicios cloud o hardware propio.
La inversión en hardware es solo el principio: las GPUs top (por ejemplo, NVIDIA H100) cuestan fácilmente 25.000 euros o más, pero el consumo eléctrico, la refrigeración y la red añaden un 40-60 % adicional (experiencia práctica).
Los costes en cloud pueden dispararse sin control —por eso el autoescalado siempre debe ir conjunto a alarmas y límites presupuestarios. Crecer en On-Premise exige planificar inversiones y amortizaciones, pero ofrece más control de costes a largo plazo.
El desarrollo y el know-how son otros drivers importantes: hay escasez de especialistas y son caros; recurrir a consultores externos puede compensar —unos 1.000–2.000 € diarios para expertos, pero da resultados rápidos y menos errores.
¡No olvide las licencias de software! TensorFlow & Co. son open source, pero licencias como NVIDIA AI Enterprise pesan. El coste total debe calcularse a tres años vista (Total Cost of Ownership, TCO).
La mejor estrategia es la progresiva: los pilotos con alcance reducido (“Minimum Viable Product”) ofrecen aprendizajes rápidos y ahorran presupuesto. Así se mantiene agilidad y se evitan sorpresas desagradables.
Implementación: Una hoja de ruta pragmática
¿Suena complicado? Se puede gestionar —con una hoja de ruta estructurada por fases. Aquí los cuatro pasos clave para arrancar en la práctica con IA:
Fase 1: Assessment y Proof of Concept (4–8 semanas)
Revíse todos los datos, procesos e infraestructura: ¿Qué hay disponible? ¿Qué hay que crear? ¿Dónde están los potenciales de negocio claros? El gran obstáculo suele ser la calidad de los datos.
Un mini-proof-of-concept con herramientas cloud disponibles (por ejemplo AWS SageMaker, Azure ML) aporta rápidamente evidencias de si un caso de uso es viable.
Fase 2: Implementación piloto (8–12 semanas)
La clave: un caso de uso claro y medible (por ejemplo, un chatbot para atención al cliente) evita derroches. Los servicios gestionados simplifican el comienzo y proporcionan experiencia sin invertir fuerte en hardware.
Implante monitorización y medición de éxito desde el inicio: Sin datos de uso y feedback, estará a ciegas.
Fase 3: Escalado y optimización (12–24 semanas)
El siguiente paso es la ampliación controlada. Con los resultados piloto, calcule necesidades de hardware y entrenamiento con precisión: sistemas sobredimensionados o insuficientes perjudican a largo plazo.
La gestión de Machine Learning Operations (MLOps) será esencial. Automatice el despliegue de modelos, backups y monitorización. Herramientas como MLflow o Kubeflow facilitan la gestión integral.
Fase 4: Operación y mantenimiento (continuo)
Finalmente, el retraining regular y la capacitación de equipos debe ser una constante. Los proyectos de IA son iniciativas en evolución: los datos y las aplicaciones cambian constantemente. El Change Management y la documentación rigurosa son ahora fundamentales.
El impacto del negocio y el ROI deben medirse y comunicarse continuamente —para que su proyecto de IA no sea un fin en sí mismo.
Preguntas frecuentes
¿Cuáles son los requisitos mínimos de hardware para aplicaciones de IA?
Para aplicaciones sencillas de IA —como chatbots— suelen bastar CPUs actuales con 16–32 GB de RAM. No obstante, los workloads de Machine Learning se benefician mucho de las GPUs: el punto de partida es la NVIDIA RTX 4090 o similar; para sistemas productivos lo habitual es usar la clase T4 o superior. Con Large Language Models, las GPUs tope de gama como la A100 o H100 y al menos 64 GB de RAM se vuelven imprescindibles.
¿Es mejor operar la IA en la nube o en On-Premise?
Ambas opciones pueden ser adecuadas: los entornos cloud son ideales para pruebas o cargas variables. On-Premise suele ser rentable cuando la carga es alta y constante, y cuando el control de los datos es esencial. Los modelos híbridos le dan flexibilidad —por ejemplo, los datos sensibles permanecen internos mientras los trabajos intensivos se trasladan a la nube.
¿Cómo integramos IA en sistemas legacy existentes?
Normalmente se utilizan pipelines ETL y sistemas de mensajería por eventos (por ejemplo, Apache Kafka). Las APIs son lo ideal, pero en sistemas antiguos suelen ser aún un objetivo futuro. Como paso intermedio, las réplicas de bases de datos o el streaming de eventos resultan prácticos. A largo plazo, es recomendable una arquitectura de microservicios que separe los sistemas existentes de los nuevos componentes de IA.
¿Qué riesgos de seguridad surgen con los sistemas de IA?
La IA amplía la superficie de ataque, por ejemplo mediante ataques a los datos de entrenamiento o manipulaciones intencionadas (Model Poisoning). Los ataques adversariales son especialmente relevantes en imágenes. Es esencial aplicar principios Zero Trust, cifrar todos los flujos de datos y auditar regularmente los modelos y las interfaces de datos utilizados. El GDPR exige que las decisiones sigan siendo trazables.
¿Con qué costes debemos contar?
Los Proof of Concept suelen moverse en el rango de 10.000–20.000 euros. Un sistema productivo puede escalar a 50.000–200.000 euros rápidamente, dependiendo de hardware, licencias y personal. Una GPU de gama alta como la H100 cuesta cerca de 25.000 euros; electricidad, refrigeración y licencias deben sumarse al presupuesto.
¿Cuánto tiempo lleva implementar una solución de IA?
Un Proof of Concept puede estar listo en 4–8 semanas; los pilotos requieren 2–3 meses. Los sistemas de aprendizaje automático complejos —especialmente cuando hay que preparar datos a fondo— pueden llevar seis meses o más. La calidad de los datos suele ser el factor que marca el calendario, más que el puro desarrollo.
¿Qué cualificaciones de los empleados son necesarias?
Al principio suele bastar con expertos externos o personal IT propio con conocimientos en datos y APIs. Saber Python ayuda, pero no es imprescindible de inicio. Con el tiempo, la experiencia en plataformas cloud, arquitecturas de datos y MLOps será clave, pero no es necesario contar con especialistas en IA desde el primer día.
