Use Cases

Computer Vision for CCTV: An Inference Architecture Built for Indonesia's PDP Law

CCTV computer vision architecture for stores and warehouses: inference in Jakarta, faces blurred first, aligned with the PDP Law. Includes an SI checklist.

CCTV analytics can align with Indonesia's Personal Data Protection Law (UU PDP) when the design starts from a narrow purpose: count, detect events, and discard everything else. The pattern on this page processes video in Indonesia, blurs faces before frames reach any model, and stores events rather than raw footage.

Status: an architecture pattern that can be built on IONext, not a project report. System integrators (SIs) and AI solution companies are welcome to use the architecture and checklist on this page in their own proposals.

What problem does computer vision solve for CCTV?

Computer vision turns CCTV footage into usable data. In stores, that means visitor counts per hour, checkout queue length, and empty shelves. In warehouses and distribution centers, it means occupational health and safety (K3) compliance, such as personal protective equipment (PPE) use and forklifts entering pedestrian zones. Without automation, footage is only opened after an incident.

This use case runs on cameras that are already installed, so the client does not need to invest in new ones. The real challenge is the data: video contains faces and behavior, which can make it personal data.

Is CCTV footage personal data under the PDP Law?

Yes, when the footage can be used to recognize a person. Article 4 of Law No. 27 of 2022 on Personal Data Protection places biometric data in the category of specific personal data, and data that is combined to identify a person is also personal data. A clearly visible face in video falls within that scope.

Article 17 sets specific rules for installing devices that process or analyze visual data in public places and public service facilities. There are three conditions: the purpose must be security, disaster prevention, or traffic management; information must be displayed in the camera area; and the device must "not be used to identify a person". The second and third conditions are waived for crime prevention and law enforcement.

The implication is that face recognition in public areas is not a safe default. If a camera in a public area is also used for business analytics, such as counting visitors, the legal basis for that processing should be discussed with the client's legal counsel from the start. A warehouse is not a public place, but video of workers is still personal data.

Does a CCTV AI project require a DPIA?

Most likely, yes. Article 34 of the PDP Law requires data controllers to carry out a data protection impact assessment (DPIA) for high-risk processing. The list covers processing of specific data, large-scale processing, systematic monitoring, and the use of new technology. CCTV analytics usually meets more than one of these criteria at once.

As of October 2026, a law firm's summary of Government Regulation (PP) No. 33 of 2026 states that AI and machine learning are an independent DPIA trigger, and that "large scale" is judged by context: volume, number of data subjects, duration, data type, purpose, and geographic scope. The regulation was promulgated on 16 July 2026 and takes effect on 16 January 2027. The DPIA remains the client's responsibility as controller, while the SI can help with a description of the architecture and data flows. See also the impact of PP 33/2026 on AI projects.

What does the architecture look like on IONext?

CCTV computer vision flow: cameras and NVR plus edge frame sampling at the client's site, then video decode, face blur, detection and tracking, events and clips, and a dashboard in Jakarta, ending with human review. IONA monitors every stage in Jakarta

The architecture has seven steps. Step one runs at the client's site; steps two through seven run in Jakarta. In this pattern, video does not leave Indonesia, and only structured events are retained long term. Workloads are managed in an ORBIT workspace, while IONA reads production signals after go-live.

Edge on site. A small gateway reads RTSP streams from the client's NVR, samples frames, and drops frames with no motion. Only relevant frames are sent to Jakarta over an encrypted connection.
Ingest and decode. Frames or stream segments reach a GPU VM in Jakarta over a private network (VPC). Video decoding runs on the GPU's hardware decoder, so the CPU does not become a bottleneck.
Anonymization. A lightweight face detector blurs every face before the frame reaches the next model, any log, or any storage. This is the most important step in the whole pipeline.
Inference. An object detection model looks for people, PPE, forklifts, or empty shelves. A tracker links detections across frames so one person is not counted many times. The model runs on IONext GPUs in Jakarta.
Business rules. Logic owned by the SI turns detections into events: visitors per hour, queues above a threshold, or zone violations.
Storage. Events go into a database in Jakarta. Short clips around important incidents are kept in private S3-compatible object storage with an automatic retention period.
Review and dashboard. Low-confidence events enter a human review queue. For incident summaries, the pipeline can send already-blurred frames to the IONext OpenAI-compatible inference API. As of October 2026, the catalog includes Qwen3.8-27B, an open-weight model that accepts image input.

Which infrastructure decisions should be made early?

The decisions that are most expensive to reverse are what gets stored and where video is processed. Both should be agreed with the client before the contract is signed. Models and GPUs can be swapped later; footage that has already accumulated cannot.

Decision	Recommended default	Why
Where processing happens	Filtering and sampling at the edge, inference in Jakarta	Sending full streams to the cloud wastes bandwidth. Centralized inference is easier to update and monitor.
What is stored	Structured events long term, incident clips short term, raw footage stays on the client's NVR	Events rarely contain personal data. Video is the highest-risk asset.
Face recognition	Not used, unless the client has a clear legal basis that has been reviewed	Article 17 requires that devices in public places are not used to identify a person, outside its exceptions.
Detection model	Apache 2.0 licensed detectors, such as RT-DETRv2, D-FINE, or RF-DETR, fine-tuned on the client's footage	The license is clear for closed commercial products. Check the license of any other model before the contract.
Tracker	A position-based tracker such as ByteTrack (MIT license)	It does not store appearance features of people. If re-identification is needed, keep the features in memory for the tracking session only.
GPU	L40S 48GB for multi-stream inference, RTX PRO 6000 Blackwell SE 96GB for fine-tuning or running several models at once	According to NVIDIA datasheets, the L40S has 3 NVDEC engines and the RTX PRO 6000 Blackwell Server Edition has 4 NVDEC engines for hardware video decoding.
Access	Private buckets, databases, and dashboards, reached through VPN or VPC	CCTV footage exposed to the public is a real data breach.

What usually goes wrong after go-live?

The problem is rarely the model. More often, the connection from the site drops, a camera is moved, or data that was meant to be temporary ends up stored for a long time. All of these can be anticipated in the design, as long as the client has an operational owner and monitoring that watches for model drift.

Dropped streams. The NVR restarts, firmware is updated, or the store's internet goes down. Set up automatic reconnect and an edge buffer, and mark hours with no data so the report does not read as a "quiet store".
Cameras moved, lights replaced, or IR mode at night. Conditions change and accuracy slowly declines. Keep a reference frame per camera and put night footage into the evaluation set from the start.
Purpose creep. Video collected for K3 is suddenly requested to assess worker performance. A new purpose needs a new processing basis and an updated DPIA. Record each purpose in the project documentation.
Leaky blur. Small faces in the distance or in profile slip past the detector. Test the blur on real footage samples, and never store pre-blur frames anywhere, including debug logs.

Replication checklist for SIs

Write down the processing purpose per camera together with the client, check it against Article 17 for cameras in public areas, and make sure CCTV information signs are in place.
Map the roles: the client as controller, the SI as processor, and the infrastructure provider as sub-processor. See how roles are split between SIs and infrastructure providers.
Help the client prepare DPIA inputs: data flows, processing locations, retention periods, and anonymization steps.
Decide what is processed at the edge and what is sent to Jakarta.
Put face blur before frames reach any model, log, or storage.
Choose the detection model and tracker, then check their licenses for commercial use.
Build an evaluation set per site type (store, warehouse) and per condition (day, night).
Set the retention period for clips and enable automatic lifecycle rules on object storage.
Set every bucket, database, and dashboard to private, then check IONA's exposed-resource alerts.
Prepare the reconnect flow, edge buffer, and no-data hour markers.
Deploy model updates through staging, with a snapshot of the previous version for restore.

Where IONext fits

IONext provides GPUs in Jakarta for decoding, inference, and fine-tuning; VMs, private networking, and object storage in the ORBIT workspace; an inference API for open-weight models; and IONA for reading production signals such as GPU memory, "stuck" pipelines, and exposed resources. Cameras, NVRs, edge gateways, detection models, business rules, dashboards, and the client relationship remain the SI's work. IONext does not provide ready-made video analytics models and does not replace the client's DPIA. Details on the ISO/IEC 27001:2022 certification and data location are on the Security and Compliance page.

Start building this pattern: sign up for IONext Console, then explore ORBIT and IONA. SIs that want to bring this pattern to retail, FMCG, or logistics clients can continue the conversation through the IONext Partner Program.

FAQ

Can a store use face recognition on CCTV? Article 17 of the PDP Law states that devices processing visual data in public places must not be used to identify a person, except for crime prevention and law enforcement. Face recognition is therefore not a default feature for store analytics. If a client still needs it, legal review is required before the design is final.

Does all CCTV video have to be sent to the cloud? No. A more efficient pattern filters frames at the edge and sends only relevant ones to Jakarta. Raw footage stays on the client's NVR under the client's retention policy.

Does processing in Indonesia automatically make a CCTV AI project compliant with the PDP Law? No. Keeping data in Indonesia removes the question of cross-border data transfer, but other obligations still apply: a clear purpose, notice in the camera area, a DPIA, a retention period, and access security. See also using LLMs on customer data under the PDP Law.

Sources

This article is general information, not legal advice. Project-specific obligations should be reviewed with legal counsel.

IONext is sovereign AI infrastructure hosted in Indonesia, operated by PT Data Awan Nusantara in Jakarta. IONext provides GPU as a Service, managed inference through an OpenAI-compatible API, and open-weight model hosting, certified to ISO/IEC 27001:2022 by TÜV NORD.