Autodesk’s October 2026 AEC Data Model API pricing change exposes an emerging gap between data residency, ownership, portability and practical control.
There is another question emerging around India's digital built environment.
It is no longer enough to ask:
Where is the data stored?
Increasingly, we may also need to ask:
On whose terms can that data continue to be accessed, interpreted and reused?
The distinction sounds technical.
It is not.
India is building airports, metros, hospitals, data centres, industrial facilities, campuses, housing and entire urban systems with increasingly sophisticated digital tools.
The information created through those projects is also becoming more sophisticated.
It is moving from drawings towards models.
From models towards structured objects.
From documents towards interconnected data.
And increasingly, from information that humans open and read towards information that software, analytics platforms and AI systems query directly.
A recent Autodesk announcement makes this transition unusually visible.
From 6 October 2026, Autodesk has announced pricing for certain Data Out activity through its AEC Data Model API.
That needs an immediate qualification.
This is not a general charge for downloading every Revit model or BIM file from Autodesk's cloud.
It does not mean that someone who owns an RVT, DWG, IFC or PDF must suddenly pay an exit fee simply to retrieve it.
Autodesk's published position is more specific.
The new AEC Data Model API rates relate to structured data moved from the AEC Data Model to external data stores. Data import, administrative activity and qualifying product-to-product use within Autodesk's platform are treated differently, and eligible subscriptions include defined amounts of API use before additional paid capacity is required.
That distinction matters.
But so does the broader direction of travel.
Because the built environment is moving from files towards data.
And once that happens, possession of the file may no longer be the same thing as practical control over the knowledge represented by it.
The fourth question in an emerging sequence
I have approached this question from three directions recently.
The first concerned digital dependency.
In What If the Software That Builds India Becomes a Trade Weapon?, I argued that India's reliance on global software, cloud environments and proprietary digital ecosystems should not lead to technological isolation.
India should continue using the best tools available.
The real objective should be strategic choice: interoperability, replaceability, portability and the ability to continue operating if commercial or geopolitical circumstances change.
Read: https://apurvapathak.short.gy/digital-sovereignty-trade-weapon
The second concerned knowledge.
In RUDRA — India's Construction Knowledge Commons, I asked whether decades of project knowledge generated across Indian architecture, engineering and construction could become a reusable national resource rather than disappearing when projects finish, teams disperse and proprietary files become inaccessible.
Read: https://apurvapathak.short.gy/india-construction-knowledge-commons-rudra
The third concerned people.
In What Should India Retain When Global Consultants Leave?, I proposed a measurable Professional Capability Dividend from major international architecture and engineering commissions.
The question was straightforward.
After the international consultant has left, what can Indian professionals do that they could not do before the project began?
Read: https://apurvapathak.short.gy/professional-capability-dividend
Those propositions can be reduced to three questions:
What does India control?
What knowledge does India retain?
What does India become capable of doing next?
The evolution of platform-based BIM introduces another:
On whose terms can India continue to access and reuse what it has already created?
Residency is not the same as sovereignty
This is where terminology becomes important.
Autodesk already provides India as a regional location for the primary storage of eligible project content.
Its AEC Data Model capabilities have also been extended to the India region.
So this should not be simplified into an argument that India's project data is necessarily sitting on overseas servers.
In fact, that development makes the deeper issue easier to see.
Data can be physically stored in India while some of the mechanisms used to structure, query, connect and reuse it remain dependent on a commercial platform.
That suggests several different layers of control.
Residency asks where the information is stored.
Ownership asks whose information it is.
Portability asks whether it can move elsewhere in useful form.
Interpretability asks whether another system can understand what has moved.
Practical access asks whether the owner can continue extracting and using that knowledge at scale without unacceptable technical or commercial dependency on the originating platform.
These questions overlap. But they are not the same.
A project owner may legally own a dataset.
The information may physically reside in India.
The source files may even be downloadable.
And yet the richer structured environment through which millions of objects can be queried, compared and connected may depend on platform-specific services, APIs and commercial conditions.
That does not necessarily constitute loss of sovereignty.
But it does create a dependency that sophisticated asset owners should understand.
Why the file is becoming less important
For much of the BIM era, information governance has revolved around files.
Who owns the model?
Who receives the model?
Which file format is required?
Which revision is contractual?
What must be handed over?
Those questions remain important.
But data-centric BIM changes the value proposition.
Consider a hospital portfolio.
The future question may not be:
Can I download the hospital model?
It may be:
Which fire doors across fifty hospitals are missing required inspection attributes?
Which medical-equipment spaces have changed after procurement?
Which air-handling units across an estate belong to a particular manufacturer?
Which room types repeatedly generate coordination problems?
Which asset classes have produced the highest maintenance frequency?
Which design decisions correlate with expensive downstream changes?
Which completed projects contain solutions that could be reused on the next one?
These are not file-management questions.
They are information queries.
The distinction is fundamental.
A 500-megabyte model may contain thousands of useful objects.
An application may need only a tiny fraction of that information.
Instead of downloading and opening the entire model, software can ask directly for particular elements, properties or relationships.
Autodesk itself describes this transition as moving from files to data.
Its AEC Data Model is designed to expose granular BIM information through APIs so that applications can query individual elements and parameters, conduct automated checking, connect project information to other systems and support cross-project analysis.
This is enormously useful.
It also changes the governance problem.
The digital asset is becoming larger than the BIM model
Consider what accumulates during the life of a major infrastructure asset.
Geometry.
Room data.
Equipment.
Specifications.
Product information.
Design decisions.
Approvals.
Coordination history.
Asset identifiers.
Commissioning information.
Maintenance requirements.
Operational records.
Performance information.
Supply-chain information.
Changes.
Exceptions.
Lessons.
Eventually, perhaps, interactions between that information and AI systems.
Over decades, that accumulated information may become more valuable than the original authoring model.
It can inform future design.
It can improve procurement.
It can support facilities management.
It can reveal recurring failures.
It can improve standards.
It can train professionals.
It can enable analytics across portfolios rather than individual projects.
It can allow AI systems to learn from actual Indian buildings and infrastructure rather than generic global datasets.
That makes the accumulated digital representation of infrastructure a form of knowledge capital.
The question is therefore no longer merely whether India possesses the files.
It is whether India can continue turning those files and their associated data into usable knowledge.
India has seen this problem before
This is not a completely new problem in Indian digital policy.
India's own GI Cloud — MeghRaj — strategy identified vendor lock-in as one of the risks associated with cloud adoption.
The government did not conclude that India should therefore reject cloud computing.
The opposite.
The strategic response was to think about architecture, standards, procurement and portability.
The GI Cloud architecture explicitly recognised the value of open standards in reducing technology and vendor lock-in and enabling multiple suppliers to participate within a common environment.
That principle translates remarkably well to the built environment.
The appropriate response to increasingly sophisticated commercial BIM platforms is not to retreat from them.
It is to design the information architecture around them intelligently.
Use the best tools.
Encourage competition.
Allow vendors to innovate.
But ensure that the accumulated information describing strategically important infrastructure does not become inseparable from whichever platform happens to be dominant at a particular moment.
Open standards matter — but they are not the whole answer
The AEC industry already has an important foundation for this.
Industry Foundation Classes — IFC — provide an open, international, vendor-neutral standard for describing BIM information.
The current ISO 16739-1:2024 standard extends this coverage across buildings and infrastructure.
That matters enormously.
OpenBIM should therefore be part of any serious long-term information-sovereignty strategy.
But even good open exchange standards do not eliminate every governance question.
A live project platform can contain far more than an exported model.
It may contain custom data.
Linked information.
Issue histories.
Workflow states.
Version relationships.
Extended properties.
Permissions.
Audit information.
Connections to operational systems.
And increasingly, machine-readable services specifically designed to allow applications and AI systems to interrogate those relationships.
So the future requirement may need to go beyond:
Give the owner an IFC at handover.
The stronger question is:
Can the owner reconstruct and continue using the information environment independently enough for another platform, another supplier or another generation of technology to take over?
That is a much higher test.
The procurement question is changing
This has implications for public-sector and major institutional procurement.
BIM requirements have often concentrated on authoring standards and deliverables.
Naming conventions.
LOD.
Coordination procedures.
Model formats.
Common Data Environments.
Handover models.
Those remain necessary.
But long-life infrastructure increasingly requires another category of requirement:
information independence.
Can structured asset information be exported in documented machine-readable form?
Are open-standard representations maintained alongside proprietary ones where appropriate?
Are classification structures and information requirements documented independently of the software implementation?
Can another vendor interpret the information without reverse-engineering the original environment?
What information disappears when a subscription ends?
What functionality disappears when an API relationship ends?
What are the commercial conditions for bulk extraction?
Are data-access costs visible during procurement rather than discovered years into operations?
Can an Indian analytics platform connect to the asset information?
Can a future AI application query it?
Can project knowledge be aggregated across a national portfolio?
Is any commercially controlled representation becoming the only authoritative expression of the asset?
These are not anti-vendor questions.
They are asset-management questions.
This is where RUDRA becomes more relevant
The Autodesk development also helps clarify the role that an India Construction Knowledge Commons should play.
RUDRA should not become an Indian Autodesk.
India does not need to recreate every commercial authoring, coordination or cloud product domestically merely to demonstrate independence.
That would confuse sovereignty with self-isolation.
Commercial platforms can remain where they are strongest:
design; modelling; coordination; collaboration; automation; analysis; construction management; asset operations.
The knowledge commons should sit at another level.
A simplified architecture might look like this:
Commercial BIM / CDE / digital-twin platforms
↓
Open exchange + documented structured extraction
↓
Owner-controlled information structures, classifications and validated knowledge
↓
RUDRA / India Construction Knowledge Commons
↓
Indian software, AI, universities, contractors, asset owners, researchers and public agencies
In that model, Autodesk, Bentley, Trimble, Nemetschek and future competitors can continue competing on tools and services.
But no vendor becomes the definition of the knowledge itself.
That distinction is fundamental.
A tool can be proprietary.
A nationally useful body of knowledge should not need to be.
And this is where the Professional Capability Dividend returns
There is also a human dimension.
It would be possible for India to mandate open formats, collect enormous datasets and still remain dependent if few Indian professionals understand the architecture underneath them.
The Professional Capability Dividend therefore belongs directly inside the digital-sovereignty argument.
On major projects, Indian architects, engineers and information professionals should progressively move beyond software operation towards understanding:
▪ information requirements
▪ classification structures
▪ schemas
▪ APIs
▪ data mapping
▪ open standards
▪ information assurance
▪ data lifecycle governance
▪ automation
▪ digital twins
▪ AI interaction with built-asset information
The objective is not merely to create more BIM modellers.
It is to develop people capable of governing the information infrastructure on which future BIM systems depend.
Because open data without capable people is not sovereign capability.
And capable people without access to accumulated knowledge are repeatedly forced to begin again.
The knowledge dividend and the human dividend therefore reinforce one another.
A five-question test for major projects
For major public and strategic infrastructure, perhaps the sovereignty discussion can be made very practical.
Before deciding that a digital information environment is adequately controlled, ask five questions.
1. Where does the information reside?
Are the project's data-residency requirements understood and contractually defined?
2. Can the information leave?
Can the owner retrieve the information in usable, documented and machine-readable forms?
3. Can another system understand it?
Are open standards, schemas, classifications and data dictionaries sufficient for meaningful interoperability?
4. Can the owner continue using it economically?
Are API access, bulk extraction, transformation, migration and long-term operational costs understood?
5. Does India gain the capability to manage what it receives?
Are Indian organisations and professionals developing the technical and institutional capacity to operate, extend and govern that information independently?
A weakness in any one of those areas does not automatically make a system unacceptable.
But the five questions reveal where dependency actually sits.
That is more useful than simply asking whether the server is located in India.
Autodesk is the signal, not the subject
The 6 October pricing change should therefore remain in proportion.
Autodesk is not suddenly charging every architect to retrieve every BIM model.
The AEC Data Model API provides genuinely useful capabilities for accessing granular information, automation and cross-project analysis.
Autodesk also offers regional project-data storage in India.
And the company is increasingly positioning Autodesk Platform Services as infrastructure for connected data and AI-enabled workflows.
Those developments are technologically significant.
That is precisely why the governance question matters.
When platforms become increasingly valuable because they do more than store files — because they structure information, expose relationships, host extended properties, drive automation and connect AI systems to project data — the terms of access to those services become part of the long-term information architecture.
The important question is therefore not:
Should Autodesk be allowed to charge for an API?
Commercial technology companies will naturally price the services they create.
The more important question is:
Has the project been designed so that a change in one vendor's API pricing, licensing model or technical strategy does not determine whether the owner can continue using its own infrastructure knowledge?
That is a governance question.
And it applies far beyond Autodesk.
From sovereignty to capability
The four propositions now begin to connect.
Digital sovereignty asks: What must India remain capable of controlling?
RUDRA asks: What knowledge generated through Indian construction should remain reusable?
The Professional Capability Dividend asks: What should Indian professionals become capable of doing because major projects occurred?
And this emerging access question asks:
Can India continue using the information it owns without being permanently dependent on the system in which that information first became useful?
Data residency is important.
Data ownership is important.
Open standards are important.
Local capability is important.
But none is sufficient alone.
The future built environment will be interpreted increasingly by machines as well as people.
Models will feed applications.
Applications will feed analytics.
Analytics will feed decisions.
AI agents will query project information directly.
Knowledge accumulated across one building will increasingly influence another.
At that point, control over the built environment's digital representation becomes part of control over the built environment itself.
The test for India should therefore not simply be whether its infrastructure data remains inside India.
It should be whether India's infrastructure knowledge remains portable, interpretable, accessible and reusable by India — across platforms and across generations of technology.
That may be the next stage of built-environment sovereignty.
And it is worth designing before dependence makes the decision for us.
