MovingLayers zeig Umsetzung der KI-Datenschutzvorgaben für KRITIS, DSGVO, BSI, NIS2

AI in Geospatial Data Processing: What Actually Needs Doing Since 2 August 2026

September 14, 2026 MovingLayers

The AI Act does not ask which software you use. It asks what happens to the data in your process. That is why the set of obligations cannot be read off a system name – only along the lifecycle of your geospatial data, from field capture to public enquiry.

Obligations Arise in the Process, Not in the System

Two topics are currently landing on the table together with striking regularity in our projects. One is the question of data sovereignty: where may, should, must geospatial data reside? The other is the AI Act: what obligations are triggered by a model that processes orthophotos or classifies utility network data?

These debates are usually held separately – one in IT architecture, the other in the legal department. In our view that is a mistake, because both rest on the same groundwork. The World Geospatial Industry Council captured it in a single sentence in a podcast episode on data sovereignty: data sovereignty is not an end in itself, but a means of managing risk. Exactly the same applies to AI classification. Both fail if you answer in blanket terms – and both work if you know which data and which systems you are actually running.

This is why we do not work from a software list, but from the chain your data actually passes through. That chain is our working model in every project – whether we are setting up a public tender, guiding a legacy system replacement, or taking over day-to-day operations and data maintenance. Since 2 August 2026, it is also the most useful assessment grid for the AI Act.

The Lifecycle of Your Geospatial Data – and Where the AI Act Touches It

At every station, requirements arise that nobody else writes down. That is now also where obligations arise. Station by station:

1 – Field Capture

Who captures data in your organisation, with which tools, in which format? External surveying firms bring their own software – and increasingly their own AI functions: automatic object recognition on photos, suggested attribute values, voice capture with transcription.

What counts here: these functions are generally not synthetic content generation and do not trigger a marking obligation. But they belong in your supplier specification, because otherwise you take AI results into your holdings without knowing that is what they are. Where capture is structured – in our case with MoversSurvey, with mandatory fields, value lists and photo documentation following your data model – it stays traceable what was measured and what was derived. That is the basis for everything downstream.

2 – Intake and Checking

The transition from the field into the database is where your data quality is either created or lost. This is where plausibility checks, topology validation and duplicate detection run – increasingly model-assisted.

What counts here: plausibility and quality checking do not generate synthetic content and do not trigger a marking obligation. The recast Article 6 expressly names quality control without a safety function as an example of what is not a safety component. What does apply here is Article 4: the people who accept or reject an AI check suggestion need the competence to judge it – and you need evidence that you have organised that competence.

3 – Data Holding

Target data model, open and OGC-compliant storage, audit-proof historisation, coordinate and height reference. This station answers the sovereignty question – and provides the memory that every AI classification will later need.

What counts here: if an AI procedure alters or supplements a dataset, it must remain recognisable later which version came from measurement and which from derivation. Anyone who historises at object level can still answer that question in five years. Anyone who overwrites cannot. Auditability is not a legal add-on but a property of the data model – and it is created in the requirements and migration phase, not afterwards.

4 – Integration

Connection to web viewers, public enquiry systems, ERP, BIM and specialist applications. This is where it is decided who uses your application – and therefore which role you take on under the AI Act.

What counts here: as long as a model is configured and used internally, you remain a deployer. As soon as the same procedure is made available externally under your name – to a municipality, a network operator, a public participation process – it can become provider status, with considerably stricter obligations. That boundary runs through the integration layer, not through the model.

5 – Analysis

Topology, longitudinal sections, point clouds, drone data, AI-assisted evaluation. This is the station carrying the most concrete obligation since 2 August 2026.

The transparency obligations under Article 50 are now applicable. For the geospatial world, Article 50(2) is decisive: providers of AI systems that generate synthetic image, audio, video or text content must mark the outputs in a machine-readable format as AI-generated or AI-manipulated. In analysis, this touches entirely everyday procedures:

generative cloud and shadow removal in orthomosaics
gap filling (inpainting) in aerial and satellite imagery
AI-assisted texturing of 3D city and building models
synthetic image datasets, for instance to train in-house models

We observe that precisely these steps have long been running in production across many process chains – often as a convenience function inside software that nobody has on their list as an “AI system”. That is the task for the coming weeks: look for the places in your existing holdings where pixels are generated rather than measured.

Where the line runs is equally important. Segmentation, object detection, classification and plausibility checking do not generate synthetic content. Nor does super-resolution automatically fall under it – purely technical upscaling is not the same as generative content creation. The line runs where the model invents image content that was not present in the source material. This can be tricky in practice, which is exactly why it belongs in your documentation. In our own analysis work – for instance with Kermit GeoAI – we carry this classification per procedure, not per product.

And legacy systems? For AI systems placed on the market before 2 August 2026, a transition period applies until 2 December 2026. As of today, that is less than three months. If you have not yet taken stock, now is the time – not because an audit is looming, but because within this window you can still realistically talk to your vendors.

6 – Decision and Public Enquiry

Plans, maps, enquiries, records – the reason you operate the system in the first place. Two very different obligations sit at this station.

First, the enquiry side. The less-discussed Article 50(1) requires AI-assisted interaction with natural persons to be recognisable as such. This concerns the information systems now springing up everywhere – the chatbot for zoning plan enquiries, the dialogue-driven application system, the cadastral enquiry with natural-language search. The obligation has applied since 2 August 2026 and is technically trivial to meet. It is simply easy to forget, because in projects it gets filed under “UX” rather than “compliance”. A fundamental rights impact assessment under Article 27 is not yet required here – that only takes effect from 2 December 2027, and only in Annex III cases.

Second, the decision itself. This is the one point in the lifecycle where geospatial data processing can genuinely become high-risk. The Digital Omnibus Regulation (EU) 2026/1744, in force since 27 July 2026, has significantly clarified high-risk classification and defused it in effect: the recast Article 6 expressly names user assistance, performance optimisation, automation, ease of use and quality control without a safety function as not safety components. Typical geospatial analysis procedures are therefore not automatically high-risk systems.

The exception sits in Annex III No. 2: AI as a safety component in the management of critical infrastructure – digital infrastructure, road traffic, and the supply of water, gas, heating and electricity. A close reading pays off here, because it touches our core business: not covered are maintaining the utility network cadastre, network documentation, and the isolated evaluation of as-built data. Covered is geospatial analysis that becomes part of safety-relevant switching, control or protection decisions in supply networks.

That is a fine line – and it does not run through the software but through the process. A network model that was documentation yesterday and feeds an automated switching logic tomorrow changes category without a single line of code changing. This is precisely why a system inventory is not enough: you need the process view. Anyone planning such integrations should carry out the classification before the project, not after it. There is time, at least: Annex III systems apply from 2 December 2027, Annex I systems from 2 August 2028.

Two Questions That Cut Across the Lifecycle

Provider or Deployer?

We now ask this among the first questions in a project, because the weight of obligations hangs on it – providers carry the stricter high-risk duties. A provider is anyone who develops an AI system, or places it on the market or puts it into service under their own name or trademark. The typical scenario in our industry: a state agency or an engineering firm adapts a pre-trained segmentation model to its own data. Three questions decide:

Is the specialist application made available under your own name?
Does the intended purpose change substantially?
Is the system substantially modified?

Internal configuration and use alone do not make you a provider. Fine-tuning for your own needs is something different from a specialist application offered to a municipality as a service. There are also easements for SMEs and small mid-caps – a point often lost in the discussion.

Article 4: The Quiet Obligation That Affects Everyone

If we had to name the provision most frequently overlooked in practice, it would be this one. Article 4 applies regardless of risk class – to all providers and deployers, however harmless the application. The obligation: take appropriate measures to foster AI literacy among staff. No particular level of competence in individual people has to be guaranteed – it is an obligation of organisation and best efforts. But it must be organised, and that means demonstrable.

For everyone whose geospatial applications are not high-risk – and that is the majority – Article 4 is therefore the central remaining organisational duty. It touches every station of the lifecycle, incidentally, because AI suggestions are accepted or rejected wherever people work with the data.

Data Classification: The Groundwork That Carries Both

This is where the circle closes back to the sovereignty debate. The WGIC podcast distinguishes three terms that are cheerfully conflated in everyday use:

Data residency – the physical storage location of the data
Data localisation – the legal requirement to store, and often also process, data within a defined territory
Data sovereignty – the right and the ability to decide on use, processing, sharing and protection yourself, irrespective of storage location

What ultimately matters is always: who holds control, and which law applies in a dispute? There is no uniform, legally binding definition of data sovereignty in Germany or the EU.

The practical consequence is the same as for AI classification: there is no blanket answer. No sensible “everything local”, no sensible “everything in the cloud”. What is emerging is a multi-layered architecture – local sovereign environments for highly critical data, regional or national sovereign clouds for controlled exchange, and globally interoperable systems for data with broad utility. The podcast aptly calls this selective sovereignty: decisions are taken according to data type, risk and purpose.

One example from the discussion is particularly instructive for geospatial practitioners: satellite imagery is often not sensitive in itself. It becomes sensitive through processing and enrichment – that is, through stations 2 to 5 of the lifecycle. It is not the raw data that decides, but its embedding and its context of use.

This very question – what kind of dataset is this, what is derived from it, what level of protection does it need – is the groundwork for the architecture decision and for AI classification. Anyone with a robust classification register can answer both questions. Anyone without one answers neither. And because classification hangs on the target data model anyway, it is best created where that model is created.

What we expressly do not recommend is isolation. Housing shortages, the energy transition, climate adaptation, disaster management – these are data-intensive and cooperation-dependent tasks. Sovereignty that sacrifices interoperability does not resolve a risk; it relocates it.

Deadlines at a Glance

Date	What applies	Lifecycle station
2 August 2026	Transparency obligations under Art. 50 – applicable	Analysis; decision and public enquiry
2 December 2026	Art. 50(2) for systems placed on the market before 2 August 2026	Analysis
2 December 2027	High-risk systems under Annex III, fundamental rights impact assessment under Art. 27	Decision (safety-relevant network control)
2 August 2028	High-risk systems under Annex I (product-related)	Integration into regulated products
ongoing	Art. 4 AI literacy – regardless of risk class	all stations

Our Recommendation: Three Steps, Now

1. Take stock along the process, not the system list. Not “where do we use AI?”, but: at which station is synthetic image content generated? That is the next deadline to fall due (2 December 2026), and the answer is often hidden in tools nobody has recorded as an AI system.

2. Document the classification – per procedure. Intended purpose, safety function, deployment environment, provider or deployer role. Four fields, one sheet of paper per procedure. In normal operation this is administrative work; in a dispute it is the decisive piece of paper.

3. Organise AI literacy. Article 4 applies now, to everyone. A documented framework with responsibilities and a training plan meets the obligation – and pays off in any case.

These three steps are, frankly, not a big undertaking – provided you know which data and systems you are running. That is precisely where it stalls in many organisations, for a structural reason: nobody has a complete picture of a system landscape grown over years from legacy systems, specialist applications and isolated solutions. This is why our work almost always begins with the same inventory that the AI Act now also requires – except that ours follows the process rather than the server room.

Where We Come In Along the Lifecycle

We accompany the full geospatial data management cycle. The three services interlock but can be commissioned individually:

Requirements management and migration – requirements as a traceable, classified catalogue, a target data model with audit-proof historisation, migration that is measured rather than hoped for. This is where the data classification is created that carries both your architecture and your AI classification.
Tendering and procurement support – we do not put software out to tender, we put a lifecycle out to tender. The AI Act, NIS2, GDPR and evidence obligations are anchored as verifiable requirements in the procedure, not as a statement of intent in the cover letter.
Operations and data maintenance – ongoing preparation, updating, map production and aerial imagery management, with logs and a documented rule set. Exactly the evidence you need when someone asks months later how a particular data state came about.

Alongside these are our own building blocks at either end of the chain: MoversSurvey for structured field capture and Kermit GeoAI for analysis. We know this chain not from a collection of methods, but because we run it ourselves.

If you are currently working out which of your procedures fall under Article 50, or how your data classification should look so that it supports architecture and AI decisions at the same time, tell us about your starting position.

Arrange an initial conversation →
View use cases →

Item added to your cart