DEV Community: Yurii Dobrytsia

Fairness in AI Is Information Governance: What OpenAI vs DeepSeek Shows About Bias, Context, and Misinformation

Yurii Dobrytsia — Thu, 14 May 2026 16:04:06 +0000

Why this article

This article was originally published on Medium. I am cross-posting it here for the developer and AI community, with the canonical link pointing to the original version.

AI Assistants Are Not Neutral Mirrors

When people compare OpenAI and DeepSeek, the discussion often becomes a race between model scores, price, openness, censorship, and speed. Those topics matter, but they miss a deeper fairness problem: large language models are increasingly used as information infrastructure.

They are not only tools that generate text. They select, compress, rank, frame, refuse, summarize, and explain. In that sense, they behave less like a static encyclopedia and more like a dynamic layer of algorithmic curation.

That matters because information is never completely neutral. A model response depends on training data, source selection, prompt wording, product rules, safety filters, regional governance, and the user's own assumptions. The result can be accurate in isolated facts while still misleading in framing.

The fairness question is therefore not only: "Is the model biased?" It is also: "How does the system decide which context becomes visible, which uncertainty is disclosed, which sources are trusted, and which interpretations are made easy?"

This article uses OpenAI and DeepSeek as a practical comparison, but the central argument is broader: fairness in AI is information governance.

From Misinformation To Decontextualization

A useful starting point is the distinction between misinformation and disinformation. Misinformation is false or misleading information spread without deliberate intent to deceive. Disinformation involves intentional deception. Moller, Hameleers, and Ferreau argue that the two dimensions that matter are facticity and intention: how close the information is to the truth, and whether the sender is trying to mislead.

This distinction is important for AI systems because not every harmful output is a hallucinated fake. Some of the most difficult cases involve real information used in a misleading way.

Decontextualization is the key example. A video, quote, statistic, or document can be genuine but still create a false conclusion when time, location, selection criteria, completeness, or causal framing are missing. In the COVID-19 debate, the #filmyourhospital example showed how real hospital footage could be used to imply a broader claim about pandemic conditions without enough context to support that conclusion.

This is where simple truth labels become too weak. If the artifact is real, a "true/false" correction does not solve the problem. The problem is the inference created around it.

AI assistants can reproduce the same pattern. A model can summarize genuine facts but omit context. It can present a dominant media frame as if it were the full debate. It can answer confidently when the right response would be qualified. It can flatten the difference between evidence, opinion, reporting, propaganda, and speculation.

Fairness therefore requires more than factuality. It requires context integrity.

Three Layers Of Bias In AI Information Systems

Bias in AI answers rarely comes from one place. It is cumulative.

First, there is source bias. Training data, web pages, news articles, forums, books, code, and institutional documents are already shaped by language, geography, politics, economics, and media incentives. If some perspectives are overrepresented, the model may learn them as the ordinary center of gravity.

Second, there is user bias. Prompts can be suggestive. A user asking "Why is X dangerous?" is not asking the same question as "What are the main arguments for and against X?" Models often try to be helpful within the frame the user provides, so a biased prompt can narrow the answer before generation begins.

Third, there is system bias. Model architecture, reinforcement learning, refusal policies, ranking logic, retrieval systems, product defaults, and safety classifiers all shape what the user sees. Even when the model is not "trying" to persuade anyone, its design choices can make some interpretations more likely than others.

This is why AI fairness should be analyzed as a pipeline:

What data was selected?
What labels or preferences shaped training?
What safety policy guides refusals and style?
What sources are retrieved?
What is ranked first?
What context is hidden?
What uncertainty is shown?
Can users challenge or inspect the result?

The answer is not just an output. It is the final visible layer of a long chain of curation.

OpenAI And DeepSeek As Two Governance Models

OpenAI and DeepSeek represent different trade-offs.

OpenAI's consumer and API systems are centralized and proprietary. Users do not receive full access to model weights or complete training data. That limits inspectability. At the same time, OpenAI publishes model behavior guidance, safety evaluations, system cards, and research on topics such as political bias. Its Model Spec explicitly frames model behavior as something that should be legible, debated, evaluated, and improved over time. OpenAI's 2025 Model Spec includes principles such as upholding fairness and seeking truth together, with guidance to avoid hidden agendas, selective emphasis, and inconsistent treatment based on irrelevant demographic details.

This is a governance-heavy model. The weakness is opacity around the underlying model. The strength is explicit behavioral governance.

DeepSeek emerged with a different public image: technical efficiency, open-weight releases, strong reasoning performance, and lower cost. DeepSeek-V3 is described in its technical report as a Mixture-of-Experts model with 671B total parameters and 37B activated per token, using architectures such as Multi-head Latent Attention and DeepSeekMoE. DeepSeek-R1 emphasized reinforcement learning for reasoning and open-sourced R1-related models and distilled variants for the research community.

This is an inspectability-heavy model. The weakness is that open weights and technical papers do not automatically solve product-level fairness, moderation, jurisdiction, or information-governance issues. The strength is that researchers can inspect, run, fine-tune, and compare the system more directly than with fully closed models.

The comparison should not be reduced to "closed is safe" or "open is fair." Both claims are too simple.

Closed systems can be safer in some abuse scenarios but harder to audit externally. Open-weight systems can improve research transparency but may vary significantly depending on deployment, fine-tuning, hosting jurisdiction, system prompts, safety layers, and application context.

The fairness question is not which brand is morally pure. It is which governance choices are visible, testable, contestable, and aligned with the use case.

Fairness Is Not Only About Demographics

In AI ethics, fairness often means avoiding discrimination based on protected traits such as race, gender, religion, disability, nationality, or sexual orientation. That remains essential. But information systems introduce another fairness layer: epistemic fairness.

Epistemic fairness concerns how knowledge is represented. Does the system give users a fair chance to understand the issue? Does it distinguish evidence from opinion? Does it show uncertainty? Does it avoid letting a dominant source ecosystem erase minority perspectives? Does it prevent malicious decontextualization without creating a private truth monopoly?

This is especially important in political, historical, medical, legal, and geopolitical topics. A model can avoid demographic slurs while still producing an unfair answer if it suppresses relevant context, overweights one narrative, or presents an unresolved dispute as settled fact.

Research on AI-generated news shows why this matters. A 2024 Scientific Reports study examined news-like content generated by several LLMs and found substantial gender and racial bias across generated content, while also noting differences between models. The broader lesson is not that one model is perfect and another is broken. It is that generated information inherits and transforms biases from data, prompts, and model behavior.

Filter Bubbles Become Conversational

The older internet fairness problem was the feed. Search engines, social media timelines, and recommender systems could personalize information until users saw less diversity of perspective.

LLMs change the interface, but not the risk. A conversational assistant can become a filter bubble in dialogue form.

The mechanism is simple:

The user asks from inside an existing frame.
The model responds within that frame.
Follow-up questions reinforce the direction.
The answer becomes more tailored, more confident, and less diverse.

This can happen without malicious intent. If a system is optimized for helpfulness, relevance, engagement, or user satisfaction, it may give the user what they appear to want rather than what would make the information environment healthier.

Sycophancy is part of this problem. A model that over-validates the user's premise may feel useful while quietly reducing epistemic friction. For fairness, sometimes the model must say: "That framing is too narrow" or "There are important counterarguments."

UNESCO's Procedural Approach

UNESCO's Recommendation on the Ethics of Artificial Intelligence is useful because it does not imagine fairness as a single truth authority. In the field of communication and information, UNESCO explicitly connects AI with access to information, disinformation, misinformation, hate speech, freedom of expression, privacy, media literacy, automated journalism, and algorithmic curation.

That is the right level of analysis. The problem is not only a bad answer. The problem is an information environment where visibility, ranking, context, and appeal mechanisms are controlled by technical systems.

The strongest governance response is procedural:

Explain why content or visibility was changed.
Provide appeal and redress mechanisms.
Preserve freedom of expression while reducing manipulative decontextualization.
Invest in media and information literacy.
Audit recommendation and retrieval systems for systematic distortions.
Make context and provenance more visible to users.

This avoids the trap of creating a central "truth machine." Instead, it asks systems to make their interventions explainable and contestable.

The EU AI Act Moves The Debate Toward Documentation

The EU AI Act adds a legal layer to the governance problem. For general-purpose AI models, the European Commission explains that providers face obligations such as technical documentation, a copyright policy, and summaries of training content. Providers of models with systemic risk face additional duties around notification, risk assessment and mitigation, incident reporting, and cybersecurity protections.

The General-Purpose AI Code of Practice, published in 2025, further organizes compliance around transparency, copyright, and safety/security.

This is progress, but it does not fully solve output-level fairness. Documentation can say what a model is and how it was developed. It does not automatically ensure that every answer separates fact from opinion, shows uncertainty, diversifies sources, or explains why one frame was selected over another.

That is the remaining gap: regulation is moving toward model documentation, but users also need answer-level transparency.

A Practical Fairness Framework For LLMs

A better fairness framework for AI assistants should combine model governance, product governance, and answer governance.

1. Context Integrity

Models should preserve the context required to interpret a fact. For images, videos, quotes, and statistics, that means time, place, source, selection criteria, and uncertainty.

2. Source Diversity

Retrieval and generation should avoid over-reliance on one media ecosystem, region, language, or political frame. Source diversity does not mean giving equal weight to unreliable claims. It means representing significant reliable perspectives proportionately.

3. Fact/Opinion Separation

Answers should clearly distinguish empirical claims, interpretations, predictions, normative judgments, and contested viewpoints.

4. Anti-Sycophancy Design

Models should be trained and evaluated not only to satisfy users, but also to challenge misleading premises politely. A fair system sometimes needs to slow the user down.

5. Visibility Explanations

If an AI system ranks, hides, labels, summarizes, or refuses content, users should understand the reason at a useful level of detail.

6. Contestability

Users and affected parties should have ways to question moderation decisions, visibility reductions, and harmful summaries.

7. Independent Audits

External audits should test not only benchmark performance but also source weighting, political neutrality, demographic bias, uncertainty handling, decontextualization, and filter-bubble effects.

8. Regional Governance Without Fragmented Truth

Different legal regions may require different compliance layers, but models should avoid silently replacing one hidden ideology with another. Regional adaptation should be visible and documented.

What OpenAI And DeepSeek Teach Us

OpenAI shows the importance of explicit behavioral governance. Its Model Spec and safety publications make intended behavior more discussable, even if the underlying model remains closed.

DeepSeek shows the importance of technical inspectability and efficiency. Its public papers and open-weight releases make architecture and training choices more accessible, even if deployment-level governance remains a separate question.

The fairer AI ecosystem will need both instincts:

The openness to inspect and compare systems.
The governance discipline to document, evaluate, and correct behavior.

Fairness cannot be reduced to open weights, closed safety layers, Western regulation, Chinese efficiency, or benchmark scores. It lives in the relationship between model design, information context, user agency, and institutional accountability.

Conclusion

AI fairness is not only about whether a model refuses hateful content or avoids demographic discrimination. It is also about whether the system helps users form informed judgments.

Misinformation and disinformation research shows that harm often comes from context loss and misleading inference, not only from fabricated facts. OpenAI and DeepSeek show that different AI systems solve different parts of the transparency problem while leaving other parts open. UNESCO and the EU AI Act show that governance is moving toward documentation, transparency, risk management, and procedural safeguards.

The next step is answer-level fairness: systems that show context, disclose uncertainty, diversify reliable sources, resist sycophancy, explain interventions, and allow users to challenge decisions.

In the AI era, fairness is not just a model property. It is the quality of the information environment the model creates.

References

Moller, J., Hameleers, M., & Ferreau, F. (2020). "Typen von Desinformation und Misinformation." Die Medienanstalten / LFK. https://www.lfk.de/fileadmin/PDFs/Publikationen/Studien/Typen-von-Desinformation-und-Misinformation/typen-von-desinformation-und-misinformation.pdf
UNESCO. (2021). "Recommendation on the Ethics of Artificial Intelligence." https://www.unesco.org/en/legal-affairs/recommendation-ethics-artificial-intelligence
OpenAI. (2025). "Model Spec." https://model-spec.openai.com/2025-09-12.html
OpenAI. (2025). "Defining and evaluating political bias in LLMs." https://openai.com/index/defining-and-evaluating-political-bias-in-llms/
OpenAI. (2026). "Inside our approach to the Model Spec." https://openai.com/index/our-approach-to-the-model-spec/
DeepSeek-AI. (2024/2025). "DeepSeek-V3 Technical Report." https://arxiv.org/abs/2412.19437
DeepSeek-AI. (2025/2026). "DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning." https://arxiv.org/abs/2501.12948
DeepSeek. "DeepSeek API Docs." https://api-docs.deepseek.com/
European Commission. "General-purpose AI obligations under the AI Act." https://digital-strategy.ec.europa.eu/en/factpages/general-purpose-ai-obligations-under-ai-act
European Commission. "The General-Purpose AI Code of Practice." https://digital-strategy.ec.europa.eu/en/policies/contents-code-gpai
Fang, X., Che, S., Mao, M., Zhang, H., Zhao, M., et al. (2024). "Bias of AI-generated content: an examination of news produced by large language models." Scientific Reports. https://www.nature.com/articles/s41598-024-55686-2

Oracle AI Database 26ai: Relational Integrity, Vector Search, and AI-Ready Financial Workflows

Yurii Dobrytsia — Thu, 14 May 2026 16:02:28 +0000

Why this article

This article was originally published on Medium. I am cross-posting it here for the developer and data engineering community, with the canonical link pointing to the original version.

The Core Question

The most interesting part of Oracle AI Database 26ai is not that it can run ordinary relational workloads. That part is expected. The more important question is how an established enterprise database changes when AI workloads become part of the same data layer.

In many AI projects, teams separate operational data, vector search, document storage, model calls, and analytics into different systems. That can work, but it introduces integration cost: duplicated data, inconsistent access control, extra synchronization, and more places where governance can fail.

Oracle's 26ai direction is different. The database is positioned as a place where structured business data and AI-oriented retrieval can live together. Relational records, JSON, graph, spatial data, text, and vector embeddings can be queried under the same database engine and security model.

This article uses a compact financial example to show why that matters. The starting point is a secured loan backed by bond collateral. The first version uses ordinary relational SQL to calculate exposure and detect undercollateralization. The stronger version adds Oracle 26ai-specific AI concepts: VECTOR columns, vector distance search, vector indexes, hybrid retrieval, and Select AI.

What Makes 26ai Relevant For AI Workloads

Oracle AI Database 26ai is the long-term-support release that replaced the 23ai naming line after the October 2025 release update. Oracle states that the release includes hundreds of new features with a focus on AI and developer productivity. The features that matter most for this article are:

AI Vector Search: Store and search vector embeddings inside Oracle Database.
VECTOR data type: Store embeddings next to business records instead of only in a separate vector database.
Vector distance functions: Use SQL functions such as VECTOR_DISTANCE with metrics such as cosine or Euclidean distance.
Vector indexes: Use approximate-nearest-neighbor indexes such as HNSW and IVF to speed up similarity search.
Hybrid search: Combine semantic vector search with keyword search through Oracle Text and vector indexing structures.
Select AI: Use natural-language prompts through SQL when an AI profile and provider are configured.

This is the Oracle-specific depth that a generic relational database introduction misses. Tables, joins, keys, and ACID behavior still matter, but in 26ai they can now be combined with semantic retrieval patterns used in RAG and agentic AI applications.

Baseline Business Model: A Secured Loan

The scenario is intentionally small. A customer receives a loan. A government bond is deposited as collateral. The loan accrues simple interest. If the collateral value falls below the current exposure, the loan status is changed to TERMINATED.

The relational model has two core entities:

BOND_COLLATERAL: stores collateral instruments and their current value.
SECURED_LOAN: stores loan contracts and references collateral through a foreign key.

CREATE TABLE BOND_COLLATERAL (
  BOND_ID      NUMBER        NOT NULL,
  BOND_NAME    VARCHAR2(50)  NOT NULL,
  VALUE_EUR    NUMBER        NOT NULL,
  CONSTRAINT PK_BOND_COLLATERAL PRIMARY KEY (BOND_ID)
);

CREATE TABLE SECURED_LOAN (
  LOAN_ID        NUMBER        NOT NULL,
  BORROWER       VARCHAR2(50)  NOT NULL,
  BOND_ID        NUMBER        NOT NULL,
  PRINCIPAL_EUR  NUMBER        NOT NULL,
  RATE_PCT       NUMBER        NOT NULL,
  START_DATE     DATE          NOT NULL,
  STATUS         VARCHAR2(12)  NOT NULL,
  CONSTRAINT PK_SECURED_LOAN PRIMARY KEY (LOAN_ID),
  CONSTRAINT FK_SECURED_LOAN_BOND FOREIGN KEY (BOND_ID)
    REFERENCES BOND_COLLATERAL (BOND_ID)
);

The foreign key is not decoration. It ensures that a loan cannot reference missing collateral. In a financial system, this kind of referential integrity is the basic layer below analytics, reporting, and AI.

INSERT INTO BOND_COLLATERAL
VALUES (1, 'GOV BOND', 100000);

INSERT INTO SECURED_LOAN
VALUES (1, 'CUSTOMER A', 1, 70000, 6.0, DATE '2026-01-01', 'ACTIVE');

COMMIT;

Now the exposure can be calculated as principal plus accrued interest:

SELECT
  L.LOAN_ID,
  L.BORROWER,
  B.BOND_NAME,
  L.PRINCIPAL_EUR,
  B.VALUE_EUR AS COLLATERAL_VALUE,
  ROUND(
    L.PRINCIPAL_EUR
    * (L.RATE_PCT / 100)
    * ((DATE '2026-01-10' - L.START_DATE) / 365),
    2
  ) AS INTEREST_EUR,
  ROUND(
    L.PRINCIPAL_EUR
    + (
      L.PRINCIPAL_EUR
      * (L.RATE_PCT / 100)
      * ((DATE '2026-01-10' - L.START_DATE) / 365)
    ),
    2
  ) AS EXPOSURE_EUR
FROM SECURED_LOAN L
JOIN BOND_COLLATERAL B ON B.BOND_ID = L.BOND_ID;

If the bond value drops to EUR 65,000, the exposure is now larger than the collateral value. The update below implements the termination rule:

UPDATE BOND_COLLATERAL
SET VALUE_EUR = 65000
WHERE BOND_ID = 1;

COMMIT;

UPDATE SECURED_LOAN L
SET STATUS = 'TERMINATED'
WHERE (
  L.PRINCIPAL_EUR
  + (
    L.PRINCIPAL_EUR
    * (L.RATE_PCT / 100)
    * ((DATE '2026-01-10' - L.START_DATE) / 365)
  )
) > (
  SELECT B.VALUE_EUR
  FROM BOND_COLLATERAL B
  WHERE B.BOND_ID = L.BOND_ID
);

COMMIT;

This is still ordinary SQL. It is useful, but it does not yet use the AI-specific capabilities of 26ai.

Extending The Example With Vector Search

Real credit monitoring does not only depend on numeric fields. It also depends on policies, internal risk rules, collateral documentation, market commentary, covenant clauses, and exception notes. Those are often text-heavy and harder to search with only exact keywords.

This is where Oracle AI Vector Search becomes relevant. Oracle 26ai supports a VECTOR data type for embeddings. A text fragment can be transformed into an embedding by an embedding model, then stored in Oracle next to its business metadata.

For example, a credit-policy table could look like this:

CREATE TABLE LOAN_POLICY_CHUNK (
  CHUNK_ID         NUMBER         NOT NULL,
  POLICY_NAME      VARCHAR2(120)  NOT NULL,
  CHUNK_TEXT       CLOB           NOT NULL,
  CHUNK_EMBEDDING  VECTOR(384, FLOAT32),
  CONSTRAINT PK_LOAN_POLICY_CHUNK PRIMARY KEY (CHUNK_ID)
);

The 384 dimension is only an example. In a real system, the dimension must match the embedding model used to generate the vectors. Oracle supports vector formats such as FLOAT32, FLOAT64, INT8, and BINARY.

Small sample fragments could describe business rules:

INSERT INTO LOAN_POLICY_CHUNK
  (CHUNK_ID, POLICY_NAME, CHUNK_TEXT, CHUNK_EMBEDDING)
VALUES
  (
    1,
    'Collateral monitoring',
    'If the exposure exceeds eligible collateral value, the loan must be reviewed and may be terminated.',
    TO_VECTOR('[0.12, 0.44, 0.31]', 3, FLOAT32)
  );

The example above uses only three dimensions to keep the SQL readable. Production embeddings usually have hundreds or thousands of dimensions.

Once the table contains many embedded fragments, a semantic search can retrieve policy text by meaning:

SELECT
  POLICY_NAME,
  CHUNK_TEXT,
  VECTOR_DISTANCE(
    CHUNK_EMBEDDING,
    TO_VECTOR(:QUERY_EMBEDDING, 384, FLOAT32),
    COSINE
  ) AS SEMANTIC_DISTANCE
FROM LOAN_POLICY_CHUNK
ORDER BY VECTOR_DISTANCE(
  CHUNK_EMBEDDING,
  TO_VECTOR(:QUERY_EMBEDDING, 384, FLOAT32),
  COSINE
)
FETCH FIRST 3 ROWS ONLY;

The important point is not the sample vector values. The important point is architectural: policy text can be retrieved semantically while remaining inside the same database environment as the loan and collateral records.

Adding A Vector Index

Exact vector search compares the query vector against many stored vectors. That is acceptable for tiny examples, but not for large document collections. Oracle supports vector indexes to make approximate-nearest-neighbor search faster.

For example, an HNSW index can be created like this:

CREATE VECTOR INDEX LOAN_POLICY_HNSW_IDX
ON LOAN_POLICY_CHUNK (CHUNK_EMBEDDING)
ORGANIZATION INMEMORY NEIGHBOR GRAPH
DISTANCE COSINE
WITH TARGET ACCURACY 95;

Oracle also supports IVF indexes:

CREATE VECTOR INDEX LOAN_POLICY_IVF_IDX
ON LOAN_POLICY_CHUNK (CHUNK_EMBEDDING)
ORGANIZATION NEIGHBOR PARTITIONS
DISTANCE COSINE
WITH TARGET ACCURACY 95;

This is a concrete Oracle-specific feature. A normal relational database chapter does not explain HNSW or IVF vector indexing. These indexes matter for AI workloads because RAG systems and agent memory stores often search thousands or millions of embedded chunks.

After indexing, a query can request approximate results:

SELECT
  POLICY_NAME,
  CHUNK_TEXT
FROM LOAN_POLICY_CHUNK
ORDER BY VECTOR_DISTANCE(
  CHUNK_EMBEDDING,
  TO_VECTOR(:QUERY_EMBEDDING, 384, FLOAT32),
  COSINE
)
FETCH APPROX FIRST 3 ROWS ONLY;

This gives up exact exhaustive comparison in exchange for speed, controlled by the index and target accuracy.

Combining Structured Rules And Semantic Retrieval

The stronger AI-data pattern is to combine relational filtering with semantic retrieval. For example, first identify loans that are undercollateralized, then retrieve the most relevant policy fragments for explaining what should happen.

WITH EXPOSURE AS (
  SELECT
    L.LOAN_ID,
    L.BORROWER,
    L.STATUS,
    L.PRINCIPAL_EUR,
    B.VALUE_EUR AS COLLATERAL_VALUE,
    ROUND(
      L.PRINCIPAL_EUR
      + (
        L.PRINCIPAL_EUR
        * (L.RATE_PCT / 100)
        * ((DATE '2026-01-10' - L.START_DATE) / 365)
      ),
      2
    ) AS EXPOSURE_EUR
  FROM SECURED_LOAN L
  JOIN BOND_COLLATERAL B ON B.BOND_ID = L.BOND_ID
),
POLICY_HITS AS (
  SELECT
    P.POLICY_NAME,
    P.CHUNK_TEXT,
    VECTOR_DISTANCE(
      P.CHUNK_EMBEDDING,
      TO_VECTOR(:QUERY_EMBEDDING, 384, FLOAT32),
      COSINE
    ) AS SEMANTIC_DISTANCE
  FROM LOAN_POLICY_CHUNK P
  ORDER BY VECTOR_DISTANCE(
    P.CHUNK_EMBEDDING,
    TO_VECTOR(:QUERY_EMBEDDING, 384, FLOAT32),
    COSINE
  )
  FETCH APPROX FIRST 3 ROWS ONLY
)
SELECT
  E.LOAN_ID,
  E.BORROWER,
  E.EXPOSURE_EUR,
  E.COLLATERAL_VALUE,
  P.POLICY_NAME,
  P.CHUNK_TEXT
FROM EXPOSURE E
CROSS JOIN POLICY_HITS P
WHERE E.EXPOSURE_EUR > E.COLLATERAL_VALUE;

This is closer to the kind of data pattern AI systems need:

Numeric exposure is calculated using deterministic SQL.
Collateral status comes from governed relational data.
Policy explanation comes from semantic retrieval.
The application does not need to copy business data into a separate vector-only store.

For a risk analyst, this could support a dashboard explanation. For an AI assistant, it could become part of a retrieval-augmented answer: "This loan is undercollateralized because exposure is EUR 70,103.56 while collateral is EUR 65,000. The relevant policy says loans exceeding eligible collateral must be reviewed and may be terminated."

The model should not be allowed to invent the numeric conclusion. SQL should calculate it. The model can help explain it.

Hybrid Search: Why Keywords Still Matter

Vector search is useful because it searches by semantic similarity. But financial and legal documents often contain exact terms that must not be blurred away, such as an ISIN, contract ID, counterparty name, legal phrase, or rating category.

This is why hybrid retrieval matters. Oracle's 26ai documentation describes hybrid vector indexes as combining Oracle Text structures with vector indexing structures. In practice, that means an application can combine:

Keyword matching for exact terms.
Vector similarity for meaning and context.
Relational filters for structured constraints such as customer, region, status, date, or exposure amount.

That combination is more robust than pure vector search for enterprise AI. A semantic search may find the right concept, but a keyword or relational predicate may be needed to anchor the result to the exact business object.

Select AI: Natural Language As A Database Interface

Oracle 26ai also includes Select AI, which allows natural-language interaction through SQL when the system is configured with an AI profile and provider.

For example, a user can ask for generated SQL:

SELECT AI showsql list all active loans where exposure is greater than collateral value;

Or run a natural-language request:

SELECT AI list all terminated loans with their collateral values;

The useful part is not that this replaces SQL knowledge. It does not. Oracle's own documentation warns that LLM outputs may be wrong and should be checked. The useful part is that a database can expose a natural-language layer while still grounding the final answer in database metadata and SQL execution.

For professional use, I would treat Select AI as a productivity interface, not as an authority. A good workflow is:

Use SELECT AI showsql to inspect the generated query.
Validate joins, filters, and aggregation logic.
Run the SQL only when the generated logic is correct.
Add comments, views, and clear column names to improve natural-language interpretation.

This point matters because many AI failures in analytics are not syntax failures. They are data-model failures: joining at the wrong level, filtering the wrong status, double-counting facts, or misunderstanding a business definition.

Strengths And Weaknesses Of Oracle 26ai For This Use Case

The strongest argument for Oracle 26ai is integration. A financial AI workflow can keep transactional records, policy fragments, vector embeddings, SQL logic, and retrieval logic closer together. That reduces the need to stitch together a separate relational database, vector database, text search engine, and governance layer.

The second strength is governance. In finance, healthcare, logistics, and government, AI systems must be built around access control, auditability, consistency, and operational reliability. Oracle's enterprise database background is relevant here because the AI features are being added to an engine already designed for controlled data.

The third strength is query composition. Oracle can combine relational predicates and vector similarity in SQL. That is valuable because most enterprise AI questions are not purely semantic. They are mixed questions: "Find the relevant policy for active loans in Germany where collateral coverage dropped below threshold after a market value update."

There are trade-offs. Oracle is complex. AI Vector Search introduces additional concepts such as embedding models, vector dimensions, distance metrics, vector memory sizing, HNSW versus IVF indexes, target accuracy, and hybrid indexing. Select AI requires provider configuration and careful validation. For small prototypes, this can feel heavier than using a lightweight database plus a managed vector service.

Cost and operational skill also matter. Oracle AI Database Free is useful for learning, but production deployments need licensing, infrastructure planning, backup, monitoring, patching, security configuration, and database administration.

What This Example Shows

The original relational workflow shows how Oracle handles structured business data: tables, keys, joins, calculations, updates, and transactions. The 26ai extension shows how the same environment can support AI-oriented retrieval:

Store policy text and embeddings in a VECTOR column.
Use VECTOR_DISTANCE to find semantically relevant fragments.
Use HNSW or IVF vector indexes for approximate search.
Combine vector retrieval with structured SQL filters.
Use Select AI as a natural-language interface, while validating generated SQL.

That is the deeper lesson: AI-ready databases are not only about storing vectors. They are about combining deterministic business logic with probabilistic retrieval in a governed data system.

Conclusion

Oracle AI Database 26ai is most interesting when it is evaluated as an enterprise AI data layer, not only as a traditional RDBMS. The ordinary relational features still matter because they provide correctness, structure, and transactional behavior. The newer AI features matter because they bring semantic search, vector indexing, and natural-language access closer to the operational data.

For the secured-loan example, SQL should calculate exposure and enforce status changes. Vector search can retrieve the relevant policy fragments and explanatory context. Select AI can help users ask questions, but the generated SQL still needs review.

This balance is the practical future of many AI systems: deterministic databases for facts and rules, vector search for meaning, and language models for interaction and explanation.

References

Oracle, "Oracle AI Database 26ai New Features Guide", May 2026. https://docs.oracle.com/en/database/oracle/oracle-database/26/nfcoa/all-nfg.html
Oracle, "Oracle AI Vector Search User's Guide", April 2026. https://docs.oracle.com/en/database/oracle/oracle-database/26/vecse/ai-vector-search-users-guide.pdf
Oracle, "Create Tables Using the VECTOR Data Type". https://docs.oracle.com/en/database/oracle/oracle-database/26/vecse/create-tables-using-vector-data-type.html
Oracle, "VECTOR_DISTANCE". https://docs.oracle.com/en/database/oracle/oracle-database/26/vecse/vector_distance.html
Oracle, "CREATE VECTOR INDEX". https://docs.oracle.com/en/database/oracle/oracle-database/26/sqlrf/create-vector-index.html
Oracle, "Create Vector Indexes and Hybrid Vector Indexes". https://docs.oracle.com/en/database/oracle/oracle-database/26/vecse/create-vector-indexes-and-hybrid-vector-indexes.html
Oracle, "Select AI". https://docs.oracle.com/en/database/oracle/oracle-database/26/selai/select-ai.html
Oracle, "Use AI Keyword to Enter Prompts". https://docs.oracle.com/en/database/oracle/oracle-database/26/selai/use-ai-keyword-enter-prompts.html
Oracle, "AI Database FAQ". https://www.oracle.com/europe/database/faq/
DB-Engines, "DB-Engines Ranking", May 2026. https://db-engines.com/en/ranking/