The FRIA Is Coming: Why AI Governance Must Assess Connectors, Permissions and Data Access — Not Just the Model

Most companies preparing for the EU AI Act’s Fundamental Rights Impact Assessment requirements are asking familiar questions.

What AI system are we deploying? What does the model do? Is the use case considered high risk? What decisions does it influence? What safeguards has the provider built into the system?

Those are necessary questions.

They may also miss one of the most important parts of modern enterprise AI: what the AI can actually reach.

An AI assistant connected only to a company’s public knowledge base presents a very different risk profile from the same assistant connected to employee email, human resources files, customer records, legal documents, financial systems and internal communications.

The underlying model may be identical.

The difference is the connector.

That distinction is becoming increasingly important as organizations prepare for Fundamental Rights Impact Assessments, or FRIAs, under Article 27 of the EU AI Act. IAPP contributor Vivek Kumar recently called attention to exactly this issue, arguing that organizations should assess the access layer surrounding AI systems rather than evaluate the model in isolation.

It is an important point because enterprise AI is rapidly becoming less like a standalone piece of software and more like an interface sitting on top of everything an organization knows.

For AI governance teams, that changes the assessment.

What is a FRIA?

Article 27 of the EU AI Act requires certain deployers of high-risk AI systems to perform an assessment of the impact the system may have on fundamental rights before deployment.

The obligation does not apply to every company using AI or even every deployer of a high-risk system. It principally applies to public-law bodies, private organizations providing public services, and deployers of specified high-risk systems involving areas such as creditworthiness and certain life and health insurance risk assessments.

The assessment must address, among other things:

• the business processes in which the AI system will be used;
• how long and how frequently it will be used;
• which individuals or groups may be affected;
• the particular fundamental-rights harms that could arise;
• human oversight measures;
• governance, complaint and remediation procedures if a risk materializes.

Article 27 also requires the FRIA to be updated when relevant aspects of the deployment change or become outdated.

That last requirement becomes particularly interesting when connectors are involved.

An organization might conduct a perfectly reasonable FRIA on Monday and materially change the risk profile on Tuesday simply by connecting the AI system to another enterprise repository.

The same AI can become a different system in practice

Consider an enterprise AI assistant used by a bank.

In the first deployment, it can access:

Public policies
Product documentation
Customer FAQs

The assistant helps employees answer routine questions.

Now give the same AI access to:

Customer transaction histories
Credit records
Internal fraud investigations
Employee email
Complaints
Customer-service transcripts

Nothing about the foundation model necessarily changed.

The organization’s practical risk changed enormously.

The AI can now retrieve information about identifiable people, combine records that were previously separated, draw inferences across different datasets and potentially expose information to employees who would never have received direct access to the underlying source systems.

A FRIA that says only:

“We use Model X supplied by Vendor Y to assist employees”

does not adequately describe that deployment.

The access architecture is part of the use case.

What exactly is an AI connector?

A connector is the technical integration that allows an AI system to interact with another application or data repository.

For example:

AI Assistant
      ↓
Connector
      ↓
Microsoft SharePoint

or:

AI Agent
   ↓
Google Drive connector
   ↓
Company documents

Modern enterprise AI products increasingly connect to systems such as:

Email
SharePoint
Google Drive
Slack
Teams
Salesforce
ServiceNow
Workday
Databases
CRMs
HR systems
Document repositories
Source-code repositories
Internal APIs

The connector can determine what the AI is permitted to retrieve.

And that can be more important to fundamental-rights risk than which large language model sits underneath the application.

The permission problem

The critical question is not merely:

What systems can the AI connect to?

It is:

Whose permissions does the AI inherit when it connects?

Imagine an employee asks:

“Summarize everything we know about Jane Smith.”

There are several radically different ways an enterprise AI system might execute that request.

One architecture limits the AI to files the requesting employee already has permission to view.

Another connector uses a service account with access to the entire enterprise repository.

The first might return three customer-support records.

The second might find:

HR records
legal correspondence
medical accommodations
financial information
executive emails
investigation files
complaints
performance reviews

The prompt did not change.

The model did not change.

The connector changed the result.

That is why permission architecture belongs inside an AI risk assessment.

AI can collapse organizational data boundaries

Traditional enterprise permissions often depend on separation.

HR has one repository.

Legal has another.

Security maintains another.

Customer service has its CRM.

Executives have sensitive email.

Finance maintains payment information.

Those systems may individually have reasonable access controls.

Enterprise AI can introduce a new layer capable of searching across all of them.

Conceptually:

HR ───────────┐
Legal ────────┤
Email ────────┤
CRM ──────────┼── AI ── User
Finance ──────┤
Security ─────┤
Documents ────┘

This changes the practical meaning of access.

Data that previously required several applications, permissions and deliberate searches can suddenly be retrieved through one natural-language prompt.

That can create what might be called aggregation risk.

No single dataset has to be improperly accessed for a problem to arise.

The danger can come from combining information that was never intended to be viewed together.

Fundamental rights are directly implicated

This matters to the FRIA because Article 27 is not merely a conventional privacy assessment.

It addresses impacts on fundamental rights.

The European Commission explains that the requirement exists because some risks cannot be understood from the AI system alone; they become apparent only when the actual context in which the system will be used is considered.

Connector permissions can affect rights involving:

• privacy and data protection;
• nondiscrimination;
• employment;
• access to essential services;
• freedom of expression;
• due process;
• effective remedy;
• human dignity.

Consider a hiring AI.

Suppose the formal system assesses:

Resume
Work experience
Education
Job qualifications

That may be the use case described in the assessment.

But someone connects the tool to Microsoft 365.

The AI can now potentially search internal communications about the candidate or current employee.

It might retrieve:

medical leave discussions
HR complaints
union-related correspondence
religious accommodation requests
pregnancy-related information
disciplinary records
private manager communications

Whether the system actually uses those records depends on the configuration and safeguards.

But if the connector makes them available, that availability belongs in the risk analysis.

Retrieval-Augmented Generation makes this especially important

Many enterprise AI products use retrieval-augmented generation, commonly called RAG.

The basic process is:

User question
↓
Search enterprise information
↓
Retrieve relevant records
↓
Provide records to model
↓
Generate answer

In that architecture, the quality and safety of the system depend heavily on the retrieval layer.

The model may behave exactly as designed and still produce a serious privacy problem because the retrieval engine supplied information it never should have received.

For example:

“Which employees are likely to leave next year?”

A connector might retrieve salary histories, HR complaints, email sentiment, medical absences and internal communications.

The model then produces a prediction.

Focusing exclusively on whether the model is accurate or biased misses an earlier question:

Should those sources have been available to the system for that purpose at all?

That is both an AI governance question and a data-governance question.

Purpose matters as much as permission

A person having technical access to information does not necessarily mean an AI system should use that information for every possible purpose.

This distinction matters.

Imagine an HR executive who legitimately has access to employee medical-accommodation records.

The company introduces an AI assistant that operates using that executive’s permissions.

Technically, the executive can access those records.

But should the assistant retrieve them when asked:

“Rank our managers by promotion potential”?

Probably not.

AI governance therefore needs to distinguish:

Can access

from:

May use for this purpose

Traditional access-control systems are not always designed to make that distinction.

They ask whether User A has permission to read File B.

AI governance increasingly needs a second policy layer:

Is information from File B permitted to be used for Task C?

That is substantially more complicated.

Connectors should be explicitly documented in the FRIA

A meaningful FRIA should therefore contain more than the model name and provider.

Organizations should document each material connector associated with the deployment.

For example:

AI system:
Internal employee assistant

Connector:
Microsoft SharePoint

Repositories:
HR policies
Employee files
Legal documents

Authentication:
User-level OAuth

Permission model:
Inherits requesting employee's permissions

Sensitive data accessible:
Yes

Special-category data:
Potentially

Cross-repository retrieval:
Enabled

Write capability:
No

Logging:
Enabled

Retention:
30 days

Human oversight:
Required for employment decisions

That begins to describe the actual deployment.

Read access and action access are different risks

The rise of AI agents makes connector assessment even more important.

A connector may allow an AI system to read information.

Another may permit the AI to take actions.

Compare:

READ:
Search employee calendar

with:

WRITE:
Cancel employee meetings

Or:

READ:
Retrieve customer account

versus:

WRITE:
Modify customer account

Or:

READ:
Review loan application

versus:

ACTION:
Reject loan application

The second category creates a very different risk profile.

Organizations should therefore inventory connector permissions by capability:

READ
SEARCH
COMBINE
EXPORT
CREATE
MODIFY
DELETE
SEND
EXECUTE
APPROVE

An AI assistant with search access is one thing.

An autonomous agent capable of executing actions across enterprise systems is another.

The connector itself can change after the FRIA

Article 27 requires organizations to update a FRIA when relevant elements change.

Connector changes are exactly the type of event that should trigger review.

For example:

New connector enabled
↓
Repository added
↓
Permissions expanded
↓
Write capability enabled
↓
New category of individuals affected
↓
New sensitive data becomes accessible

Any of these could materially alter the assessment.

That means AI governance cannot treat the FRIA as a PDF generated before deployment and then forgotten.

The assessment must connect to change management.

The DPIA and FRIA increasingly intersect

Many organizations subject to Article 27 will also need to consider a Data Protection Impact Assessment under the GDPR.

The AI Act specifically recognizes this overlap. Where applicable, the FRIA should be conducted together with the DPIA rather than forcing organizations to duplicate substantially overlapping analysis.

Connectors are one of the clearest places where those two assessments meet.

The FRIA asks:

What fundamental-rights consequences could this AI deployment create?

The DPIA asks, among other things:

What risks arise from processing personal data?

The connector determines:

What data can the system actually reach?

Those questions cannot sensibly be separated.

A practical AI connector assessment

Organizations preparing their assessment process should inventory at least the following for every connector:

Connector name

Connected application

Data repositories accessible

Categories of personal data

Special-category or sensitive data

Authentication method

User-level vs service-account access

Read permissions

Write permissions

Delete permissions

Action permissions

Cross-system retrieval

Purpose restrictions

Data retention

Prompt and output logging

Third-party exposure

Human oversight

Access review frequency

Incident controls

The organization should then test the connector rather than rely exclusively on documentation.

Ask the AI deliberately difficult questions.

Try to retrieve information from departments the test user should not see.

Attempt cross-repository searches.

Test whether changing user permissions immediately changes AI retrieval.

Ask whether deleted or restricted documents continue to appear in embeddings or indexes.

Test whether the model can infer sensitive attributes from otherwise permitted sources.

In other words:

Red-team the access layer, not only the model.

AI inventories need to become AI dependency maps

Many organizations are currently creating AI inventories.

That is a good start.

But an inventory containing:

Microsoft Copilot
ChatGPT Enterprise
Internal recruiting model
Customer-service chatbot

does not reveal much about actual risk.

A useful AI governance program needs something closer to:

AI SYSTEM
    ↓
MODEL
    ↓
CONNECTORS
    ↓
DATA SOURCES
    ↓
PERMISSIONS
    ↓
PURPOSES
    ↓
AFFECTED PEOPLE
    ↓
DECISIONS / ACTIONS

That is an AI dependency map.

And it provides much more useful information for a FRIA.

The FRIA is ultimately about the deployment, not just the product

This may be the central lesson of Article 27.

Two companies can buy exactly the same AI product and create entirely different fundamental-rights risks.

One connects it to public documentation.

Another connects it to HR, email, customer records and financial information.

One limits permissions to those of the individual user.

Another gives the AI a privileged enterprise service account.

One allows search.

Another allows the AI agent to make changes and execute transactions.

The vendor may supply the same model in every case.

But the deployer determines the environment.

That is precisely why the EU AI Act places the FRIA obligation on certain deployers rather than assuming the model provider can identify every contextual risk in advance.

The European Commission says certain fundamental-rights risks can only be fully identified once the actual context of use is known.

Connectors are part of that context.

They determine what the AI sees.

They determine which datasets can be combined.

They determine whose information can be retrieved.

Increasingly, they determine what the AI can do.

As organizations build their EU AI Act compliance programs, assessing the model while ignoring the connector layer creates a major blind spot.

The right question is no longer simply:

“What can this AI model do?”

It is:

“What can this AI model do with everything we have allowed it to reach?”

That is the system that needs to be assessed.