La Ley N° 19.628 de 1999 quedó obsoleta frente a la economía digital. Chile actualiza su normativa para alinearse con estándares internacionales como el RGPD europeo y la LGPD brasileña, reconociendo la protección de datos como un derecho fundamental. La Ley N° 21.719 no deroga la anterior — la reescribe sustancialmente, introduciendo una agencia fiscalizadora autónoma, nuevos derechos para los titulares y un régimen sancionatorio de primer nivel.
Fecha de vigencia y período de transición
El Consejo Directivo de la APDP debe quedar designado antes del 1 de junio de 2026, conforme a la Ley 21.806. Las organizaciones que no estén listas al 1° de diciembre de 2026 quedan expuestas al régimen sancionatorio completo.
Ámbito de aplicación: ¿a quién aplica?
La ley aplica a toda persona natural o jurídica, pública o privada, que realice tratamiento de datos personales de personas naturales. No existe umbral de tamaño ni de volumen de datos para quedar sujeto a sus obligaciones — desde una startup hasta una multinacional están bajo su alcance.
El alcance es también extraterritorial: aplica aunque el responsable no tenga presencia física en Chile, si sus operaciones están destinadas a ofrecer bienes o servicios a titulares ubicados en territorio chileno. Este principio sigue el modelo del RGPD europeo Quedan excluidos:
Tratamiento de datos en ejercicio de libertad de opinión e información (medios de comunicación)
Datos tratados por personas naturales en actividades estrictamente personales o domésticas
Roles clave: Responsable y Encargado del Tratamiento
Los contratos con proveedores de servicios cloud o SaaS deben incluir cláusulas de tratamiento de datos que cumplan con la Ley 21.719. Sin estas cláusulas el responsable puede enfrentar sanciones aunque la vulneración la cometa el proveedor.
Principios que rigen el tratamiento de datos
Bases de licitud: cuándo es legal tratar datos
Todo tratamiento requiere una base jurídica válida. El consentimiento (Art. 12) es la regla general, pero no el único camino. El Art. 13 reconoce cinco fuentes alternativas de licitud que no requieren consentimiento expreso del titular.
El consentimiento no debe usarse como comodín. Si existe otra base de licitud aplicable, es preferible usarla — el consentimiento puede revocarse en cualquier momento.
Obligaciones económicas, financieras, bancarias o comerciales Reguladas en el Título III de la ley.
Cumplimiento de obligación legal Cuando la ley exige el tratamiento de datos para cumplir un mandato normativo.
Ejecución de un contrato Cuando el tratamiento es necesario para cumplir un contrato entre el titular y el responsable.
Interés legítimo del responsable Con límites y ponderación frente a los derechos del titular.
Misión de interés público O ejercicio de potestades públicas conferidas al responsable
Datos Sensibles: régimen de protección reforzada
El Art. 16 define categorías de datos cuya exposición puede causar discriminación o daño irreparable. Tratarlos sin base legal es la infracción más grave: hasta 20.000 UTM. Su tratamiento requiere consentimiento explícito o una base de licitud reforzada.
Las bases de datos que contengan estas categorías requieren controles de acceso más estrictos, cifrado de datos en reposo y tránsito, y la realización de Evaluaciones de Impacto en la Protección de Datos (EIPD) antes de iniciar el tratamiento.
Derechos del titular: ARCOP+B
La ley reconoce seis derechos ejercibles por el titular. El responsable tiene 30 días corridos para responder desde la recepción de la solicitud. El incumplimiento puede derivar en multas de hasta 10.000 UTM por parte de la APDP.
La Agencia de Protección de Datos Personales (APDP)
la Ley 21.719, encargado de fiscalizar, investigar y sancionar el incumplimiento de la normativa. Representa el cambio más estructural respecto a la ley anterior: por primera vez Chile contará con una autoridad de control independiente con facultades reales de enforcement.
Puede iniciar investigaciones de oficio o por denuncia de titulares
Emite instrucciones generales y guías de cumplimiento
Aplica sanciones graduadas según gravedad de la infracción
Consejo Directivo debe quedar designado antes del 1 de junio de 2026 (Ley 21.806)
Las sanciones escalan desde 100 UTM (~$7,1M CLP) para infracciones leves hasta 20.000 UTM (~$1.430M CLP) para las gravísimas — como el tratamiento ilícito de datos sensibles.
Obligaciones técnicas clave para equipos de TI
Hoja de ruta hacia el cumplimiento
La cuenta regresiva hacia el 1° de diciembre de 2026 ya comenzó. Organizaciones que inicien hoy tienen tiempo suficiente para cumplir en forma ordenada. Quienes esperen al último trimestre enfrentarán presión operacional y riesgo de sanciones desde el primer día de vigencia.
01 Inventario de datos Mapear todos los flujos de datos personales: qué se recopila, para qué, dónde se almacena y quién accede.
02 Identificar bases de licitud Asignar una base legal válida a cada tratamiento. No usar el consentimiento como comodín.
03 Actualizar contratos Revisar acuerdos con proveedores cloud y SaaS para incluir cláusulas de encargado de tratamiento.
04 Implementar derechos ARCOP+B Habilitar canales y procesos internos para responder solicitudes dentro de los 30 días corridos exigidos.
05 Política de privacidad Publicar aviso de privacidad obligatorio con toda la información exigida por la ley.
06 Plan de respuesta a brechas Definir protocolo de detección, contención y notificación de incidentes de seguridad.
Capa de middleware semántico entre agentes de IA/LLMs y sistemas clínicos
Conectan de forma segura los modelos de lenguaje con fuentes de datos clínicos heterogéneas
Habilitan la orquestación en tiempo real de datos del paciente con trazabilidad completa
Valor Estratégico para la Salud
Interoperabilidad avanzada entre sistemas heterogéneos (EHR,DICOM, laboratorios) • Integración de IA en flujos de trabajo clínicos existentes sin fricción • Orquestación de datos del paciente en tiempo real para decisiones clínicas • Cumplimiento con estándares HL7 FHIR y DICOM
Los MCP Servers actúan como intermediarios semánticos entre los sistemas hospitalarios y los agentes de IA.
Telecomunicaciones Detección preventiva, diagnóstico automatizado y corrección inteligente en sistemas BSS/OSS
Los equipos de soporte técnico en telecomunicaciones operan en modo reactivo: esperan a que el problema ocurra, lo detectan manualmente, diagnostican con herramientas aisladas y aplican correcciones caso a caso. Este modelo es insostenible frente a la complejidad creciente de los sistemas BSS/OSS y los volúmenes de incidentes actuales.
Detección Tardía:
Los problemas en aprovisionamiento, facturación y pedidos se detectan cuando ya impactaron al cliente o generaron una reclamación. No existe visibilidad proactiva sobre degradaciones en curso
Diagnóstico Fragmentado:
Cada sistema (OMS, CRM, billing) tiene sus propias herramientas de monitoreo. El diagnóstico cross-system requiere intervención manual de múltiples equipos, alargando el MTTR.
On this page we will provide an introduction to the AWS Cloud Adoption Readlines Tool (CART). Which allows you to assess the status of your organization for the adoption of Amazon Web Services Cloud services. CART is a powerful tool that will allow you to successfully face the use of Cloud AWS technologies. 3HTP offers you the following possibilities:
Schedule an appointment with a 3HTP AWS Architect who will accompany you in the process of filling in and interpreting the results:
If you would like to do it yourself send us your information. You will receive an email with detailed instructions on how to do it:
The path to cloud services, the Bridge2Cloud as we call it in 3HTP, has become a necessity for companies in search of immediate resource provisioning, elastic scalability and high availability.
However, one of the main barriers when thinking about migrating to the cloud is the ignorance of the current state of the organization when thinking about Cloud Adoption.
How to evaluate?
Where to start?
What areas should be considered?
How to set priorities?
What elements should be considered?
These are some of the questions that remain unanswered when we want to start a cloud adoption plan.
AWS Cloud Adoption Readiness Tool
You will answer a questionnaire that allows, through simple questions, to evaluate the current state of the organization. This tool has the objective of providing a guide that helps organizations in the construction of a migration strategy to the Amazon Web Services cloud. The application allows us to:
Know what state you are in to migrate to AWS services.
Obtain a roadmap with the areas in which you must work within the organization.
Obtain a PDF report with the details provided by each of the questions asked.
The CART allows an assessment to be made to see how prepared you are to adopt cloud services by following 16 questions that are designed based on AWS best practices.
It is useful for companies of any size and any sector, giving the possibility of detailing the state of readiness to adopt cloud services
How is the CART structured?
The evaluation questionnaire is made up of two types of questions.
Classification questions between 1 to 5 where you must answer depending on the capacity of your organization in a given situation or activity.
"yes" or "no" questions that must be answered in the event of the existence or non-existence of some element in the organization.
This survey and evaluation report details your preparation for the migration to the cloud through 16 questions grouped into six perspectives:
Business
Persons
Processes
Platforms
Operations
Security
CART is a totally free tool that AWS has for all users.
Schedule an appointment with a 3HTP AWS Architect who will accompany you in the process of filling in and interpreting the results:
If you would like to do it yourself send us your information. You will receive an email with detailed instructions on how to do it:
"Customers migrating to AWS can experience a 51% reduction in operations costs, a 62% increase in IT staff productivity, and a 94% reduction in downtime."
At present, the topic of Containers and Orchestration is generalized due to its growth in the world of information technologies, its advantages, and the great promises it raises. Different vendors and brands (Oracle, IBM, Microsoft, RedHat, AWS) are introducing new concepts related to these issues and therefore new products are emerging. But what is the usefulness of container technology? What do we gain from containment? Why is it a solution to some of the current problems in technology areas?
Most people have heard of Docker, and see it as the only Containerization technology, but it is not the only solution on the market, although it is true that to date it is the most successful and is the one that has allowed generalization. of the concept. Containerization technology already existed before Docker, it is a technical concept related to the construction of Linux kernels, and how they allow certain levels of isolation.
In the world of container technology we have:
Docker: It is the flagship product of the Docker Company
Cri-o: It is the technology that RedHat chose to be able to support its containers in OpenShift, which is its Orchestration platform
LXC: Native Linux-based Container Deployment
Orchestration platforms for these containers we have:
Docker Swarm,
Kubernetes a Google Product
RedHat Open Shift
CONTAINERIZATION
We all know virtualization technology, where Virtual Machines require hardware, a hypervisor, a base operating system for applications, and a level of resources for their operation. It is a very useful technology that is still used and that will continue to be used for a long time and longer in the cloud world.
Unlike virtualization, containers are a new way of encapsulating an instance, placing everything in a single product “Container” where inside is placed what the application needs to operate, the Operating System, the platform, and the application. Although it really is an abstraction, it does not require, for example, the entire Operating System. The container is not a virtual machine so I don’t need 100% of all items, just what the application actually needs, this makes it a very lightweight way to encapsulate.
Fig. 1. Disi, R 2020. Comparación VIrtualización Vs Contenerización, Diseño 3HTP
Unlike the traditional approach, where the developer shares everything that is necessary for the application, packages, patches, libraries, and that is installed in the QA and production environment and then the environment, configuration, version problems, etc. start. With the containers, these problems are avoided, since the image comes with everything that the application needs, and in this way, there is no difference between the environments since the developer delivers the container and it is exactly the same as what is sent to QA and Production.
The following graphic shows a Docker platform that will be taken as an example to explain how the container concept works, although all the products are similar and even have similar names.
Doker is easy to understand, it has a client-server architecture that is the Docker host where the “Docker” software is installed and where it runs from an image, an application, or an operating system, an instance called a container. This allows multiple containers of the same image to be installed, you could have an image that had a Java application, and you could have other instances with different names that would be on the same Docker host in the same environment.
On the other hand, you have the “Registry” which is a kind of repository that I publish my images centrally, the idea is that the same Registry is used and that there is a Docker Host for Development, one for QA, one for Production, etc. . In this way, the image of the same repository is always obtained, so it is ensured that the exact copy, Operating System, Platform and the environment is installed.
In addition, it has a client layer that allows the execution of commands that can be done locally and allows quickly and simply to execute different types of applications and different technologies, whether I can prepare it or I can obtain it from public repositories such as Docker Hub (https://hub.docker.com/), which is one of the best known. Currently, the different brands have already published certified Docker images, which allows developers to obtain them and speed up the development process.
Then the approach changes, the Container technology allows us to move or move with the image of the application through each environment, creating instances of the image because they physically correspond to the same object, revolutionizing the work cycle and the DevOps and automation world, well now The only concern is to obtain the image with the correct version in the Registry, making the work cycle much faster, since there are no longer such long installation steps or parameterization, since the application is already ready in its environment.
However, there are still those tasks associated with connecting to databases, integrations with external applications or services, that is, the external is not solved with this technology. However, it is still a great advance in the world of development and automation for the deployment of applications, reducing risks associated with different environments.
Esta tecnología hace que la imagen sea agnóstica, se olvida completamente del entorno pues todo lo que requiere el aplicativo está en el contenedor, por eso no se recomiendan prácticas como la configuración de artefactos condicionados a cada ambiente, pues no tiene sentido en este nuevo escenario.
ORCHESTRATION
We have already briefly described what the concept of containers consists of, the benefits it brings and to some extent its limitation with respect to external connections and services. However, if I want to use containers in complex environments, where for example I have containerized applications, the application server is separated from the data layer and the web layer, both in different containers instead of having three VMs.
In this scenario, new problems appear, what happens if I want to scale, if I need to balance and have high availability, how to communicate those containers that need to be connected, how can I monitor the containers and see which one requires a greater or lesser number of resources at some point.
So how do we solve these questions, I need a tool that allows me to solve these problems. To respond to these needs, the Orchestration platforms emerge Kubernetes, Openshift, and Docker Swarm, which are similar solutions that allow me to work in a more elaborate way with containers.
Fig 5. Arquitectura Kubernetes
The image shown takes the Kubernetes structure as an example and shows the different elements and concepts that are similar in all Orchestration systems. They have business support, an infrastructure base system that saves time in the installation and configuration of the infrastructure to run a cluster and other elements such as the Master, the Workers, the latter is the one that executes the applications. It has clusters that are formed with more than one instance (pods) of containers and an Etcd repository, a database where all the configuration is stored among other components.
It also has a component, in this case, the kubetctl, which allows interacting with the master through command lines and it sends instructions to each of the workers, in such a way that the master allows me to scale horizontally or vertically, redistributing the load if a worker is added to it, this really allows us to have what is defined in the literature as a dynamic cluster.
“The concepts are very similar to the architectures of a Java and J2E application server with the concepts of domain, node agents, cluster, and so on. Unlike J2E, where only business applications are allowed to run under the standard, in the case of container orchestration platforms, any type of technology-independent applications can be implemented “
Nowadays the different cloud providers have monitoring solutions that allow automating the scalability of the resources in the Orchestration platforms that allows, at a time, to manage the number of resources up or down depending on the demand.
In this sense we have two great strengths: with containers, you gain all the power to encapsulate applications independent of the technology in which it is developed, and with the Orchestration layer you get the power to manage to have high availability, scalability, elasticity, and sharing. environments, which allows the use of resources when required by those applications that at certain times generate increases in demand. All of the above is conceptually and technically possible. However, these concepts require a process of understanding and maturing. Both the container technology and the Orchestration layers require a large number of resources, for example, if we want a high availability solution for a master, cluster solutions of 3 – 5 – 9 are required, which means having resources, machines of a certain capacity.
IN WHICH SCENARIO CAN WE USE CONTAINMENT TECHNOLOGY?
Today we have two scenarios or focuses in which we turn to Containerization and Orchestration technology: the first focus is the modernization of existing applications. Specifically, business applications that run in a Unix environment or in an environment that lends itself to being portable, Java, J2E, etc. There are companies that are exiting the proprietary Unix world and opting for other variants. This modernization is given for a few reasons:
Accelerate the life cycle.
Improve application availability and scalability
Prepare for migration to a cloud platform
Many brands are already supporting their containerized platforms, many factory servers that already have container portability, not the database world that still has a long way to go. One of the modernization techniques used in this approach is Reshapes, a Cloud Adoption technique that allows with little modification to create a container.
Modernization faces some challenges, one is the homologation, the configuration and the dependency of the applications which has several techniques to solve these tasks. Another challenge is that some of the brands do not support old versions of the same products. Another aspect is the structure of the applications that you want to migrate and that are not designed or developed to allow elasticity and are not prepared to work with more than one instance. In addition, in this new environment, developers must know not only about Containerization, but they must also know about the development of traditional applications.
The other focus is design and development from the ground up for Containers and Orchestration. This technology gives me very innovative design elements to work in a modular way, where you can have components in different containers and that their sum conforms to a more complex, more elastic application, more traceability, and tolerance to different scenarios.
The native development in containers also offers possibilities to advance, there are brands that clearly support their products in this technology, there is a great variety of components for different problems that they present. On the other hand, some challenges remain, such as the knowledge that must still be acquired about this technology and breaking the inertia and paradigms in the design and development of applications, forgetting traditional architectures.
Containerization and Orchestration form one of the verticals and types of technologies within the Cloud Landscape levels that allows the development of applications in a more portable way allows correcting or reducing deficiencies that exist in the development and deployment processes of The solutions still have great lines of development and challenges to overcome, but it is one of the variants to take into account when making a decision in the world of information technology.
Fig. 6 Cloud Native Landscape, 2019.
Containerization is one of the technologies that are present in the Cloud world, it allows to greatly reduce many of the problems that exist today in the development, automation and deployment processes of an application.
We can say that containers are a portable way of defining software, and Orchestration is a portable definition of how that software should be executed, deployed and monitored.
Renzo Disi | Director 3HTP | Santiago de Chile | Talk on Containerization and Orchestration | 2020
DEVOPS AND CONTAINERS | IMPORTANT ACTORS OF AGILITY
The world of technology continues with great advancement and innovation and DevOps and Containerization technologies are an example of this. Over the years they have developed new concepts and are the focus of the technical and operational areas, which seek agility, automation in management and reduction of time, advantages that the correct adoption of DevOps processes and the use of container technology.
Due to the increase and speed of technological leaps, the software market needs to produce high-quality results in a short time, increasing agility and limiting the number of life cycle errors (ALM). In this scenario, DevOps has the challenge of being part of the solution and overcoming the traditional problems of the IT areas: definition meetings, management of procurement and infrastructure processes, coupling of areas for the governance model, among others.
On the other hand, containerization technologies bring all the characteristics to simplify the application management process, allow portability between environments (on-premises – Cloud), and centralize the tasks of the operation teams, thus giving agility and mobility to the software, without losing sight of the implications of automation and management with DevOps.
The “everything as code” has been opening an important framework for the development of skills within the software cycle, which suggests incorporating scripting strategies within DevOps in order to optimize the way the included processes are automated.
We are going to involve these concepts to expose the benefits of the successful implementation of DevOps, taking innovation technologies hand in hand.
Phases of the 3HTP methodology
Within the adoption phase (first phase of the 3HTP methodology) it is important to transform the concepts of on-premises software installations and lead to dynamic models where solutions from infrastructure as code (Iac), application containerization, platforms as a service and script enablement participate. and/or plugins for the software execution of the toolchain; This is called Hybrid DevOps and what is known is the ability to define a faster implementation strategy.
In the DevOps Software market we find many solutions that offer these possibilities, but what is really important is to know how to define the tools that “contribute to my current business reality”, that is, that the analysis of the toolchain to be implemented is given by the scope it has each tool versus the functionalities that are needed in the objective outlined as an implementation roadmap.
Hybrid DevOps allows mixing these technology concepts to accelerate the step to professionalization (Phase 2 of the 3HTP methodology) and at the same time provide as an example automation measures, decrease in infrastructure costs, use of resources, and above all agility. We also find continuous integration engines that allow the execution of Jobs, with integration to automation tasks to the software and execution tasks of availability and provisioning of complete platforms for the applications.
The diagram of the graph Nr2 shows an example of an implementation that could be given by different types of software solutions to contribute to the toolchain: The Artifact and Image Source repositories (now with the Containers trend) that are generally almost part of an asset for the company for its value and importance. On the other hand, a continuous integration engine with a pipeline that allows the execution of the DevOps phases to involve the creation of the container where the software that needs to be called to fulfill a task at a certain point in time (compilation, code analysis, unit tests, etc.), called infrastructure scripts as code, which allow the creation and provisioning of an environment, for example for the QA Testing phases, which are of “volatile” necessity and finally the call to scripts that automate a task by itself or by means of software. Finally, it also allows team collaboration and continuous improvement with feedback and feedback to the ALM solution, which could be software as a service (JIRA, VSTS, EWM, etc).
The speed of the Development teams and the technology area must be given by the implementation of solutions that contribute and give that speed that the market exists and that agility that is talked about so much. The adoption of technological tools today can be seen from different points of view and the use of resources is a vital part of the goals that IT has.
It is time to refocus the processes and adoption model, and launch into the management of a Hybrid DevOps architecture to meet the needs of the organization; It is time to increase the scripting skills of the teams involved in DevOps (Development, Testing, infrastructure, production) and start laboratories of these new solutions that help in the way of reducing time and costs.
In the next few years, DevOps faces optimizing and improving partitions that have been created in the middle phases of the CI / CT / CD / RM lifecycle process, and getting started delivering a tunnel (pipeline) that truly connects end to end. end-to-end Development with uninterrupted Operations and with the standards of Automation, quality, agility, security that the software and applications require.
Cognito is the proposal that Amazon offers among its services to organizations to reduce the investment of time and effort in the development of the authentication platform for their applications.
Fecha de vigencia y período de transición
Fecha de vigencia y período de transición
