# Aionios > Consultora chilena de ingeniería de datos. Construimos plataformas de datos en Google Cloud y Microsoft Fabric, explotamos datos de SAP e implementamos los controles técnicos que exige la Ley 21.719 de protección de datos personales. - Sitio: https://aionios.cl - Cobertura: Chile (remoto, con presencia en terreno cuando el proyecto lo requiere) - Idioma: español - Contacto: contacto@aionios.cl - LinkedIn: https://www.linkedin.com/company/aionios-chile/ - Instagram: https://www.instagram.com/aionios_cl/ - Ficha extendida: https://aionios.cl/ai ## Qué hacemos Equipo de dos socios: uno con experiencia funcional en SAP MM y operaciones, otro en arquitectura de datos en la nube. Proyectos de alcance acotado, construidos sobre la infraestructura del cliente, con código y documentación entregados en su repositorio. ## Servicios Índice: https://aionios.cl/servicios ### Data engineering URL: https://aionios.cl/data-engineering Resumen: Diseñamos y construimos pipelines de datos en BigQuery, Airflow y Dataform: ingesta desde SAP y otras fuentes, modelamiento por capas y cargas automatizadas. Stack: BigQuery, Airflow / Cloud Composer, Dataform, Google Cloud, Microsoft Fabric, Cloud Run, Python, SQL Términos: data engineering, ingeniería de datos, pipelines de datos, ETL, ELT, BigQuery, Airflow, Dataform, automatización de cargas Entregables: - Ingesta desde ERP (SAP), bases transaccionales, APIs y archivos, con cargas incrementales y reproceso controlado. - Modelamiento por capas (raw, staging, core, marts) con las reglas de negocio versionadas en SQL, no escondidas dentro de un tablero. - Orquestación en Airflow (Cloud Composer) o Dataform, con dependencias explícitas, reintentos y ventanas de carga. - Tests de calidad sobre los datos: unicidad, integridad referencial, frescura y rangos esperados. - Documentación y código en tu repositorio, desplegable desde cero sin nosotros. Casos de uso: - Consolidar compras y consumo de materiales de SAP MM en BigQuery, para dejar de pedirle una extracción a TI cada vez. - Reemplazar una planilla mensual que cruzaba tres fuentes a mano por una carga diaria automatizada con control de errores. - Unificar datos de varias plantas o filiales con estructuras distintas en un solo modelo comparable. - Preparar una capa analítica para tableros que hoy consultan la base transaccional y la dejan lenta. Preguntas frecuentes: - ¿Qué hace un ingeniero de datos? Construye y mantiene el camino que recorre un dato desde el sistema donde nace hasta el reporte donde se usa: extracción, limpieza, modelamiento, orquestación y monitoreo. No es lo mismo que un analista, que interpreta el dato, ni que un desarrollador de aplicaciones, que construye el sistema de origen. - ¿Hay que migrar todo a la nube para empezar? No. Casi siempre partimos por un dominio acotado —compras, inventario, ventas—, lo dejamos funcionando de punta a punta y recién ahí se decide qué sigue. Migrar todo de una es la forma más cara de descubrir que el modelo estaba mal. - ¿Cuánto demora tener el primer pipeline en producción? Con un dominio acotado y acceso a las fuentes, entre 4 y 8 semanas hasta tener carga automática, tests y un tablero encima. Lo que más mueve el plazo es conseguir los accesos a los sistemas de origen, no el desarrollo. - ¿Trabajan con datos de SAP? Sí, y es parte de por qué existimos: uno de los dos socios viene de SAP MM y operaciones. Extraemos los datos y además sabemos qué proceso los generó, que es de donde suelen venir las diferencias entre el ERP y el reporte. ### DataOps URL: https://aionios.cl/dataops Resumen: Orquestación, tests de calidad, alertas y CI/CD sobre plataformas de datos existentes. Menos incidentes silenciosos, menos costos sorpresa en la nube, menos dependencia de una sola persona. Stack: Airflow / Cloud Composer, Dataform, BigQuery, GitHub Actions, Cloud Monitoring, Microsoft Fabric, Python, SQL Términos: DataOps, calidad de datos, observabilidad de datos, monitoreo de pipelines, CI/CD de datos, gobierno de datos, costos BigQuery Entregables: - Tests automáticos de calidad y frescura que detienen la carga antes de que el dato malo llegue al tablero. - Alertas accionables: qué se rompió, en qué tabla y a quién le importa. - CI/CD para las transformaciones: pull request, revisión y despliegue reproducible en vez de editar en producción. - Ambientes separados de desarrollo y producción, con accesos por rol. - Monitoreo de costos y tiempos de ejecución en BigQuery o Fabric, con alertas de presupuesto. - Runbooks escritos: qué hacer cuando falla cada cosa, para que no dependa de nosotros. Casos de uso: - Una plataforma heredada que funciona, pero que nadie se atreve a modificar porque no hay pruebas. - Cargas que fallan en silencio y se descubren cuando un usuario nota que el dato quedó viejo. - La cuenta de BigQuery subió el triple y nadie sabe qué consulta la está moviendo. - Todo el conocimiento de despliegue está en la cabeza de una persona. Preguntas frecuentes: - ¿Cuándo conviene invertir en DataOps? Cuando ya hay pipelines en producción y alguien depende de ellos para decidir. Señales concretas: un número equivocado llegó a una reunión, el pipeline se arregla a mano, una sola persona sabe desplegar, o la factura de la nube subió sin explicación. Antes de eso, con tests básicos y alertas basta. - ¿Qué diferencia hay entre DataOps y data engineering? Data engineering construye el pipeline. DataOps es lo que hace que siga funcionando: pruebas, despliegues, monitoreo, control de accesos y costos. En equipos chicos lo hace la misma gente, pero es trabajo distinto y se puede contratar por separado. - ¿Sirve si la plataforma la construyó otro proveedor? Sí. Buena parte de este trabajo es sobre plataformas heredadas: partimos por levantar qué hay, qué se cae y qué cuesta, y priorizamos por riesgo. No exigimos reconstruir para poder operar. - ¿Cómo se controla el costo de BigQuery? Casi siempre con lo mismo: particionar y agrupar las tablas grandes, cortar los SELECT * que dispara el tablero, materializar lo que se consulta muchas veces, y poner alertas de presupuesto por proyecto. El costo se domina midiendo qué consulta escanea qué, no apagando cosas al azar. ### Arquitectura cloud URL: https://aionios.cl/cloud-architecture Resumen: Diseño de la plataforma de datos en Google Cloud o Microsoft Fabric: organización de proyectos, accesos, conectividad al ERP, control de costos y plan de migración por etapas. Stack: Google Cloud, BigQuery, Cloud Run, Cloud Storage, IAM, Microsoft Fabric, Azure, Infraestructura como código Términos: arquitectura cloud, consultora cloud en Chile, Google Cloud, GCP, Microsoft Fabric, Azure, plataforma de datos, migración a la nube Entregables: - Estructura de proyectos o workspaces, con ambientes separados y nomenclatura consistente. - Accesos por rol con privilegio mínimo, cuentas de servicio y revisión de quién puede leer datos sensibles. - Elección fundamentada entre Google Cloud y Microsoft Fabric, según dónde vive hoy tu operación. - Conectividad hacia el ERP y sistemas on-premise, incluida la salida de datos y sus costos. - Presupuestos, etiquetado de recursos y alertas de gasto por área. - Plan de migración por etapas, donde cada etapa deja algo funcionando por sí sola. Casos de uso: - Definir desde cero la plataforma de datos de una empresa que hoy vive en planillas y en el ERP. - Ordenar una cuenta cloud que creció sin estructura, sin detener lo que ya está corriendo. - Decidir entre seguir en el ecosistema Microsoft o construir la capa analítica en Google Cloud. - Conectar un ERP on-premise con una plataforma analítica en la nube. Preguntas frecuentes: - ¿Google Cloud o Microsoft Fabric? Depende de dónde ya está tu empresa. Si la operación vive en Microsoft 365 y el reporting es Power BI, Fabric reduce fricción e integración. Si el volumen de datos es alto, hay equipos técnicos y se necesita control fino de costo por consulta, BigQuery suele salir mejor. Trabajamos con ambos y la decisión se toma con tus números, no por preferencia. - ¿Cuánto cuesta una plataforma de datos? Son dos costos distintos. El consumo de nube en un primer dominio suele ser la parte menor: BigQuery cobra por almacenamiento y por datos escaneados, y un modelo bien particionado rara vez es la línea grande de la factura. El costo dominante es la implementación, y ahí preferimos un alcance acotado con precio cerrado antes que un proyecto anual abierto. - ¿Podemos aprovechar lo que ya tenemos? Casi siempre sí. Reescribir todo es la salida cómoda para el proveedor y la cara para el cliente. Partimos por inventariar qué funciona, qué se cae y qué nadie usa; lo que sirve se conserva. - ¿Y si nuestros sistemas están on-premise? Es lo normal con un ERP. Se resuelve con una capa de extracción que corre cerca del origen y publica hacia la nube en ventanas definidas, cuidando el volumen que se mueve y por dónde sale. No es necesario migrar el ERP para tener analítica en la nube. ### Business intelligence URL: https://aionios.cl/bi-analytics Resumen: Modelamiento analítico y tableros en Power BI sobre una capa semántica común: cada métrica definida una vez, con dueño, y no tres veces en tres áreas. Stack: Power BI, DAX, BigQuery, Microsoft Fabric, Looker Studio, SQL Términos: business intelligence, Power BI, tableros, dashboards, modelo semántico, KPI, reportería, Looker Studio Entregables: - Modelo analítico en estrella sobre la capa de datos, con dimensiones conformadas y granularidad explícita. - Diccionario de métricas: definición, fórmula, fuente y responsable de cada indicador. - Tableros en Power BI orientados a una decisión concreta, no a mostrar todo lo que hay. - Seguridad a nivel de fila cuando cada gerencia debe ver solo lo suyo. - Traspaso al equipo interno para que puedan crear sus propias vistas sin romper el modelo. Casos de uso: - Reportería de compras y abastecimiento que cuadre con SAP y se pueda explicar línea a línea. - Reemplazar un set de planillas mensuales por un tablero con datos del día anterior. - Consolidar indicadores de varias gerencias que hoy se calculan distinto. - Ordenar un Power BI que creció hasta volverse lento e imposible de mantener. Preguntas frecuentes: - ¿Por qué cada área tiene un número distinto? Porque la definición vive en el archivo de cada quien. Mientras la métrica se calcule dentro del tablero, cada tablero es una definición nueva. Se resuelve moviendo el cálculo a una capa común, versionada, y dejando el tablero como una vista de esa capa. - ¿Power BI o Looker Studio? Power BI cuando hay licencias Microsoft, necesidades de modelo semántico serio, seguridad por fila y distribución interna amplia. Looker Studio cuando se quiere algo liviano sobre BigQuery, con pocos usuarios y sin modelamiento complejo. La herramienta importa mucho menos que tener la capa de datos ordenada debajo. - ¿Pueden trabajar sobre los tableros que ya tenemos? Sí. Es frecuente que el diagnóstico termine en conservar dos o tres tableros, arreglar el modelo que hay debajo y eliminar el resto, que nadie abría. - ¿Cuántos tableros necesito? Menos de los que crees. Un tablero que nadie mira dos veces por semana es mantenimiento sin retorno. Preferimos pocos, con dueño y con una decisión asociada. ### Protección de datos · Ley 21.719 URL: https://aionios.cl/ley-21719 Resumen: Inventario del tratamiento de datos personales, plan de adecuación priorizado por riesgo e implementación de controles técnicos: clasificación, accesos, trazabilidad y anonimización. Stack: BigQuery, Dataplex, Sensitive Data Protection (DLP), IAM, Cloud Audit Logs, Microsoft Purview, SQL Términos: Ley 21.719, protección de datos personales Chile, cumplimiento normativo, ARCOP, anonimización, inventario de datos personales, Agencia de Protección de Datos Personales Entregables: - Inventario de tratamiento de datos personales: qué dato, en qué sistema, con qué finalidad y bajo qué base de licitud. - Mapa de flujos y transferencias, incluidos proveedores y sistemas fuera de Chile. - Plan de adecuación priorizado por riesgo, no por lo que es más fácil de cerrar. - Clasificación y etiquetado de datos sensibles en las bases donde efectivamente están. - Control de accesos y trazabilidad: quién consultó qué dato personal y cuándo. - Anonimización y enmascaramiento para ambientes de desarrollo y pruebas. - Un proceso ARCOP que se pueda operar: cómo entra la solicitud, quién la resuelve y en qué plazo. Casos de uso: - Una empresa que sabe que debe cumplir, pero no tiene inventario de dónde están los datos personales. - Datos de clientes replicados en planillas y ambientes de prueba sin ningún control. - Solicitudes de titulares que hoy se responderían a mano, buscando en varios sistemas. - Un asesor legal que ya redactó las políticas y necesita que alguien las implemente en los sistemas. Preguntas frecuentes: - ¿Desde cuándo rige la Ley 21.719? Entra en vigencia el 1 de diciembre de 2026. Desde esa fecha la Agencia de Protección de Datos Personales puede fiscalizar y sancionar, y las obligaciones se aplican sobre los tratamientos que ya estén en curso. - ¿Qué es una solicitud ARCOP? Es el ejercicio de los derechos del titular sobre sus datos: acceso, rectificación, cancelación, oposición y portabilidad. En la práctica implica poder encontrar todos los datos de una persona en tus sistemas y actuar sobre ellos dentro de plazo, lo que es un problema técnico antes que legal. - ¿Basta con publicar una política de privacidad? No. La política declara lo que haces; la ley exige que además lo hagas y lo puedas demostrar. Sin inventario, control de accesos y trazabilidad no hay cómo acreditar el cumplimiento frente a una fiscalización. - ¿Son un estudio de abogados? No. Somos ingenieros de datos. La redacción legal la hace tu asesor jurídico; nosotros levantamos dónde están los datos y dejamos implementados los controles técnicos. Trabajamos bien en conjunto con el abogado, no en su lugar. - ¿Por dónde empiezo? Por el diagnóstico de madurez que está en este mismo sitio: son 8 preguntas, menos de 5 minutos y no tiene costo. Al terminar tienes un nivel de madurez y una recomendación concreta de qué atacar primero. ### SAP y explotación de datos del ERP URL: https://aionios.cl/sap Resumen: Consultoría funcional SAP MM y extracción de datos del ERP hacia tu plataforma analítica: compras, materiales y abastecimiento, con el contexto del proceso que los generó. Stack: SAP MM, BigQuery, Microsoft Fabric, Power BI, Python, SQL Términos: SAP MM, consultoría SAP, datos SAP, extracción SAP BigQuery, abastecimiento, maestro de materiales, reportería SAP Entregables: - Consultoría funcional en abastecimiento: compras, maestro de materiales, inventario y procesos asociados. - Extracción de datos de SAP hacia BigQuery o Microsoft Fabric, con cargas incrementales y validación contra el origen. - Modelamiento de los datos del ERP en un formato analítico entendible fuera de SAP. - Reportería sobre el ERP y conciliación entre lo que muestra SAP y lo que muestra el tablero. - Automatización de tareas repetitivas del proceso de abastecimiento. Casos de uso: - Reportería de compras que debe cuadrar con SAP y explicarse línea a línea. - Maestro de materiales con clasificación inconsistente que ensucia todo el análisis de consumo. - Consolidar datos de SAP con fuentes externas para analizar abastecimiento completo. - Un proceso de abastecimiento que consume horas de digitación cada semana. Preguntas frecuentes: - ¿Qué parte de SAP conocen? MM: compras, maestro de materiales, inventario y los procesos de abastecimiento alrededor. No hacemos desarrollo ABAP ni implementaciones completas de SAP. Entramos donde el proceso de abastecimiento se cruza con los datos y el reporting. - ¿Cómo se llevan datos de SAP a BigQuery? Con una extracción programada sobre las tablas o vistas del ERP, cargas incrementales por fecha de documento y una validación que compara totales contra el origen. La parte difícil no es el transporte: es decidir qué tablas representan el proceso real y cómo se reconstruye la lógica del ERP fuera de él. - ¿Por qué mi reporte no cuadra con SAP? Las causas frecuentes son tres: se está comparando a granularidades distintas (documento contra posición), hay movimientos anulados o modificados que el extractor no recoge, o el maestro de materiales cambió y el histórico quedó con la clasificación antigua. Las tres se detectan conciliando contra el origen, no ajustando el tablero. - ¿En qué industrias han trabajado? Minería, energía, telecomunicaciones y retail, principalmente en procesos de abastecimiento y control de gestión. ## Otras páginas - https://aionios.cl/diagnostico: diagnóstico de madurez en protección de datos, gratuito, 8 preguntas. - https://aionios.cl/blog: blog técnico. - https://aionios.cl/privacidad: política de privacidad. - https://aionios.cl/arcop: ejercicio de derechos ARCOP. ## Blog - https://aionios.cl/blog/ley-21719-que-cambia: Ley 21.719: qué cambia para las empresas en Chile. Un resumen práctico de las obligaciones que trae la nueva ley de protección de datos personales.