Zero-Based Data Budgeting: Design the Feature Before Collecting the Data

By Kenny Trinh and Kira

Most companies do not intentionally design a complicated data footprint. It accumulates.

A feature needs a name and email address. An event is added to an analytics platform. A payload gets copied into application logs. Microservices pass the same information through queues, caches, and databases. An AI feature arrives later and creates another reason to retain everything “for improvement.”

Then compliance work begins.

The company inventories systems, traces personal information, defines retention policies, and tries to determine whether sensitive data is appearing somewhere it should not. This is necessary work, but it starts after the hardest decisions have already been made.

A better approach is to give every feature a data budget from the beginning.

Start from zero

Zero-based budgeting in finance asks teams to justify expenses from scratch instead of treating last year’s spending as the default.

Zero-based data budgeting applies the same idea to information.

For every feature, begin with the assumption that it receives, stores, and shares no personal data. Then add only what is required to produce the intended business outcome.

The central question is simple:

Can we deliver the same feature with less data?

Walk through the feature from beginning to end:

1. What outcome does the user need?
2. What is the minimum information required to produce it?
3. Which service needs each field?
4. Does that service need the original value, or would a reference or derived value work?
5. Must the information be stored?
6. If so, for how long?
7. Where could it be copied unintentionally?

This turns data minimization from a policy into an engineering constraint.

Give each service its own budget

Microservice architectures make this especially important.

A request might move through an API gateway, an application service, a message broker, a worker, an analytics pipeline, and several data stores. If the original payload travels through the entire chain, every component becomes part of the sensitive-data footprint.

Instead, examine each boundary separately.

A payment notification service may need to know that a transaction succeeded, but not need the complete payment record. An analytics service may need a customer segment, but not the customer’s name or email address. A background worker may need an internal record identifier, but not the personal information associated with it.

The data budget should shrink as information moves through the system, not expand by default.

This also applies to operational tooling. Logs, traces, error reports, support systems, and dead-letter queues are easy to overlook because they are not part of the primary database. In practice, they are often where unnecessary copies accumulate.

Apply the same method to AI

AI systems create a strong temptation to retain broad datasets because they may be useful later.

But “we might use it to improve the model” is not a precise data requirement.

Suppose we want to evaluate and improve an AI feature. We can ask:

• Which specific behavior are we measuring?
• Do we need the full input and output, or only evaluation signals?
• Do we need names and email addresses?
• Can direct identifiers be removed or replaced?
• Can the analysis run on normalized or aggregated data?
• Can we sample a smaller dataset?
• Can access be limited to a narrower group?
• How long must the examples remain available?

The answer may still be that some original data is necessary. Zero-based data budgeting does not forbid collection. It requires us to state why each category exists and add it deliberately.

That distinction matters. It is the same principle I have found useful when designing personal AI systems: start with a narrow, high-leverage surface instead of granting access to everything.

Build privacy as a roadmap

Starting with the minimum does not mean building a permanently limited product.

It means treating additional collection as a product decision.

A team might begin an AI feature using de-identified evaluation records. Later, it may determine that a carefully sampled set of original conversations is needed for a specific quality problem. That can become an explicit roadmap item with its own access controls, retention period, consent requirements, and deletion process.

The sequence becomes:

1. Deliver the feature with the smallest practical dataset.
2. Measure what the current data cannot tell us.
3. Add a narrowly defined category only when it supports a concrete need.
4. Review whether the additional data is still earning its place.

This is safer than collecting everything first and trying to govern it afterward. It also produces cleaner systems. Fewer unnecessary fields mean fewer permissions, fewer accidental leaks, simpler deletion, and a smaller compliance surface.

Data should have to justify its existence

Privacy-first design is sometimes treated as a final review performed by legal or security teams. By then, information may already be embedded in schemas, APIs, logs, integrations, and operating habits.

Zero-based data budgeting moves the decision back to the drawing board.

For every feature and every service, start at zero. Add the minimum information required to complete the business outcome. Make each additional field justify its collection, movement, retention, and access.

The goal is not to process no data.

It is to ensure that every piece of data in the system is there because we made a conscious decision to put it there.