Databases

Structured stores you query

Structured databases are often the richest source of reliable data in an organization, but getting an AI to query them safely requires understanding both what is in them and who should be allowed to touch them.

Databases hold the work that has been systematized: customer records, transaction histories, product catalogs, support logs, inventory. Unlike documents or notes, this data is already structured, which means an AI with access to it can do genuinely precise work: filter, aggregate, find patterns, answer specific questions. That precision is also why access needs to be carefully considered.

Most databases were not designed with AI access in mind. They were designed for applications and for humans with specific roles. Giving an AI broad read access to a database that contains sensitive personal or financial data without first understanding its schema, its access model, and what a wrong query could expose is a meaningful risk. The goal is targeted, read-appropriate access, not open-ended connectivity.

Make it visibleList every database your team uses, note what it contains and whether it holds sensitive data, and mark which have read-only access available. That inventory is the prerequisite to any safe AI integration with structured data.

Why AI needs this

Each part of your work matters to AI in a specific way. Some of it is context a tool needs before it can help, some of it is work a tool can take on, and some of it is judgment that should stay with you.

What the database actually contains

Before connecting anything, document what each database holds: customer records, transactions, product data, or internal logs. The type of data determines what access is appropriate.

Query access versus write access

An AI reading from a database and an AI writing to one are very different risk levels. Read-only access is usually the right starting point; write access needs a clear rationale and tight controls.

Schema clarity

A database whose table names and column names are clear lets an AI generate useful queries. One with cryptic field names or undocumented relationships produces unreliable results even when access exists.

Personal and sensitive data

Databases that hold personal data are subject to data-protection rules. Any AI access needs to fit within the permissions already granted by users and the policies already in place.

Questions to explore

Use these on your own or in a group. There are no right answers, only better conversations.

What databases does your team maintain or have access to, and what type of data does each one hold?
Does any AI tool currently have access to a database, and if so, was that access explicitly scoped and reviewed?
Which databases hold personally identifiable or financially sensitive information, and what data-protection obligations apply to them?
How well-documented is the schema of each database: could someone unfamiliar with it write a useful query without guidance?
Are there databases that contain important operational data but were set up years ago and are now poorly understood by the current team?

Readiness traps

A database with broad read access can expose far more than intended. A query that joins tables unexpectedly can surface sensitive data that no one thought to restrict. Start with the minimum access needed.
Databases with poorly documented schemas produce confident-sounding but incorrect results when an AI generates queries against them. Always verify outputs against known data before trusting them in production.
Old databases that were never decommissioned often sit alongside active systems and hold stale or contradictory data. An AI that cannot tell old from current will mix them.