Machine learning

Decide what leaves before it leaves

Calling a model that runs somewhere else means sending it data. The decision about which fields may go is usually made once, verbally, by whoever built the integration. Here it is a set of rules the platform applies to every call and records the outcome of.

What a rule can decide

Allow

The field goes as it is.

Mask

The field goes with its value obscured, so the shape survives and the content does not.

Transform

The field goes as something derived from it rather than as itself.

Require approval

The call waits for a person. Some data should leave, but not on a schedule and not unattended.

Block

The field does not go. If the model needs it, the call does not happen.

How the decision is reached

Rules are per field

Because the question is per field. A record with one restricted column in it is not a record that must stay whole or leave whole.

The most specific rule wins

Rules are ordered by how specifically they match, so a general default can be set without having to anticipate every exception.

There is always a default

A field no rule names still gets an answer. What that default is, is a decision you make rather than one the platform makes quietly.

Sensitivity feeds it

Features and columns carry their classification, so rules can be written about personal data rather than about column names that change.

Decisions are recorded

What was allowed, masked, transformed or blocked on a given call is kept as an event, which is what makes the control auditable rather than merely configured.

The plan is separable from the call

What would leave can be worked out and read before anything is sent, so the answer to "what does this integration send" does not require running it.

Why this is not the same as masking in the pipeline

Masking applied during a transform changes the data for everyone downstream, which is often exactly wrong: the analyst who needs the real value and the external model that must never see it are two different consumers of the same column.

Egress control acts at the boundary instead. The dataset keeps its values, the platform keeps its lineage, and the decision about what crosses the line is made per call, per field, at the point where it matters.

Questions about egress

Does this apply to AI model calls as well as ML models?

The platform already applies egress policy to AI steps. The ML layer reads the same policy, so there is one answer to what may leave rather than one per subsystem.

What happens if a required field is blocked?

The call is refused, and the refusal is recorded as a blocked run with its reason. A call that quietly proceeded with a missing field would produce a result nobody could interpret.

Can I see what would be sent before sending it?

That is the intent of keeping the plan separable from the call: the decision for each field can be produced without invoking anything.

Where this is today

The machine learning layer is in build. What is described on this page is the data and governance model that is implemented in the platform: the tables that hold it, the rules that enforce it, and the refusals that happen when a rule is not satisfied.

The Data Science tab is in the application. It reads: the model registry and its versions, the approval held for each version in each environment, the integrations and whether each one may currently be called, the record of every run including the refused ones, the projects, and the egress rules. It does not invoke a model - running belongs to the execution provider, and the record of a run is audit evidence that a browser must not be able to write.

Talk to us about the ML layer

DataLens is in private beta. If model governance is the reason you are here, say so when you request access - the ML layer is being built against real use rather than a roadmap.

Request beta access