Knowledge Graph Internal vs Knowledge Graph Publik: Apa Bedanya

Di satu layar, tim data punya graph yang luar biasa detail.

Customer segment.

Contract status.

Owner internal.

Product dependency.

Risk level.

Subsidiary code.

Draft acquisition.

Partner tier.

Internal project.

Semua terhubung.

Lalu marketing bilang:

“Publish aja graph ini ke website biar AI makin ngerti.”

Jangan.

Knowledge graph internal dan knowledge graph publik punya tujuan, data sensitivity, governance, dan audience yang berbeda.

Mereka bisa saling berhubungan.

Mereka tidak harus identik.

Kesalahan paling berbahaya adalah menganggap “lebih banyak data publik = lebih bagus untuk AI”.

Tidak.

Public graph harus memenuhi principle yang jauh lebih ketat:

Benar.

Relevan.

Aman.

Intended for public use.

Maintainable.

Useful.

Internal graph punya kebebasan lebih besar karena ia melayani operasi organisasi.

Apa Itu Knowledge Graph Internal?

Internal knowledge graph adalah representation entity dan relationship yang digunakan di dalam organisasi.

Entity bisa:

Customer.

Employee.

Team.

Office.

Product.

Service.

Contract.

Vendor.

System.

Campaign.

Project.

Dataset.

Document.

Ticket.

Policy.

Risk.

Relationship bisa:

Owns.

Assigned to.

Depends on.

Contracted with.

Approved by.

Uses.

Blocked by.

Escalated to.

Located in.

Internal graph dapat menghubungkan data dari CRM, ERP, CMS, HR, product database, asset management, dan knowledge base.

Tujuan:

Search internal.

Data governance.

Automation.

Analytics.

Recommendation.

Access control.

Operations.

AI agent context.

Tidak semuanya layak keluar dari firewall.

Apa Itu Knowledge Graph Publik?

Public knowledge graph yang dimaksud dalam konteks website adalah subset identity dan relationship yang memang intended untuk publik.

Contoh:

Organization.

Brand.

Public leadership.

Products.

Services.

Locations.

Public research.

Articles.

Authors.

Events.

Datasets.

Partners yang memang announced.

Parent/subsidiary relations yang public.

Certifications.

Public evidence.

Public graph dapat direpresentasikan melalui:

Visible content.

Structured data.

Internal linking.

Feeds.

Sitemaps.

Public APIs.

Entity pages.

Public data files.

Tujuannya:

Clarity.

Discovery.

Verification.

Navigation.

Interoperability.

Public search.

Machine understanding.

Trust.

Bukan membuka database internal.

Boundary Pertama: Privacy

Internal graph bisa tahu:

Employee salary.

Personal phone.

Home address.

Performance review.

Customer contract value.

Lead status.

Vendor dispute.

Security incident.

None of this belongs in public graph by default.

Even if “AI could understand us better”.

No.

Data minimization.

Privacy law.

Security.

Business confidentiality.

Human dignity.

Public entity strategy must never override those.

Person pages are especially sensitive.

Publish only professional/public information relevant to role.

Not enrichment for the sake of graph density.

Boundary Kedua: Commercial Confidentiality

Internal graph:

Product X depends on vendor Y.

Launch date secret.

Margin 62%.

Enterprise customer A has churn risk.

Acquisition target B.

Public graph should not leak.

The fact that data is structurally useful does not make it publishable.

Marketing and engineering need publication policy.

Never auto-export entire internal ontology to JSON-LD.

Structured data is public.

Anyone can read it.

“Tidak kelihatan di halaman” does not mean private.

JSON-LD in source is public.

Boundary Ketiga: Epistemic Status

Internal graph can contain hypothesis.

Lead suspected industry.

Risk estimate.

Probabilistic relationship.

Draft parent mapping.

Public graph should distinguish verified fact from inference.

Example:

Internal:
“Company A likely affiliated with Group B, confidence 0.72.”

Public:
Do not publish “Company A is part of Group B” unless verified and appropriate.

Internal graph can be exploratory.

Public graph must be evidence-controlled.

This is huge.

AI teams love probabilistic inference.

Website cannot casually turn inference into fact.

Boundary Keempat: Relationship Granularity

Internal graph may need:

Product team → owns → feature.

Feature → blockedBy → dependency.

Employee → reportsTo → manager.

Public graph may only need:

Product → offered by → Organization.

Article → authored by → Person.

Organization → parentOrganization → Group.

Granularity follows use case.

Don't publish thousands of edges that have zero user value.

Public graph is not a transparency dump.

It is curated information architecture.

Conversation yang Wajib Terjadi

Data engineer:
“Graph internal kita punya 200 ribu edges.”

Marketing:
“Kita publish yang public.”

Legal:
“Definition public siapa yang pegang?”

Security:
“Any identifiers leak?”

HR:
“Person data?”

Product:
“Draft products?”

SEO/GEO:
“Which relationships actually help user understand entity?”

This meeting may feel bureaucratic.

Actually it's governance.

Knowledge graph touches truth across departments.

One team should not decide alone.

Source of Truth Bisa Sama, Projection Berbeda

Best architecture often:

One governed internal entity registry.

Then public projection.

Example internal Organization node:

Entity ID.

Legal name.

Tax identifier.

Internal ERP code.

Legal address.

Billing address.

Risk status.

Internal owner.

Public URL.

Brand.

Leadership.

Public social.

Parent.

The public website projection exposes only:

Name.

Legal name if appropriate.

Public URL.

Logo.

Public address/contact.

Brand.

Public leadership.

Parent relation.

Relevant identifiers.

Same source, different view.

This reduces inconsistency without exposing sensitive fields.

Think database view.

Not database dump.

Public Graph Butuh Provenance

If page says:

“Company A acquired Company B in 2025.”

Source?

Press release.

Regulatory filing.

Official announcement.

Public graph edge:
A acquired B.

Should have provenance internally.

Public page doesn't need RDF provenance complexity.

But editorial system should know evidence.

If challenged, team can verify.

Internal graph can store:

Source URL.

Effective date.

Reviewer.

Confidence.

Status.

This is governance advantage.

Internal graph supports public truth.

Structured Data Hanya Salah Satu Public Projection

Public graph is not equal to JSON-LD.

Visible content is critical.

Entity page.

Relationship section.

Breadcrumb.

Internal link.

Author bio.

Product data.

Organization details.

Structured data expresses some of that machine-readably.

Not every internal edge has Schema.org property.

Don't invent random properties in public JSON-LD.

If Schema.org doesn't model an internal relation cleanly, keep it internal or express it in prose.

Semantic correctness > completeness.

Knowledge Graph Publik Bisa Lebih Kecil tetapi Lebih Kuat

Internal:
50 entity types.

Public:
8.

Internal:
200 relation types.

Public:
15.

Fine.

Public power comes from clarity and consistency.

Organization.

Person.

Brand.

Product.

Service.

Place.

Article.

Evidence.

If those core nodes are clean, public graph can be excellent.

No need to expose internal complexity.

Actually reducing complexity often makes maintenance easier.

Freshness Cadence Berbeda

Internal graph may update real time.

CRM lead status every minute.

Inventory every second.

Employee role daily.

Public graph update cadence depends on fact.

Product availability:
potentially frequent.

Leadership:
when changes.

Office:
when changes.

Article:
publish/update.

Certification:
renewal.

Company structure:
corporate event.

Public graph doesn't need real-time everything.

But stale public facts are bad.

Define SLA per fact type.

Leadership update within X business days.

Location same day.

Product discontinuation immediate.

Research version explicit.

Governance matters more than graph technology.

Internal IDs vs Public IDs

Internal entity ID:
ORG_482918.

Public canonical URI:
https://example.id/#organization.

Do not expose internal database primary key unless intentional and safe.

Public ID should be stable, meaningful as identifier, and not leak system architecture.

Internal graph can map:

ORG_482918 ↔ public URI.

This decouples backend migration from public identity.

If database IDs change, public entity doesn't.

Stability valuable.

Access Control Exists Only Internally

Internal graph nodes/edges can have ACL.

HR relationship only HR.

Legal relationship only legal.

Finance only finance.

Public graph by definition is accessible publicly.

You cannot meaningfully “hide” JSON-LD with CSS.

If delivered to browser, assume public.

This must be understood by teams who think structured data is invisible.

Invisible visually ≠ private.

AI agents and scrapers can read source.

Search engines can.

Competitors can.

Users can.

Only publish what is safe.

Can Internal Graph Power an AI Assistant?

Yes.

Internal agent can use richer graph under authorization.

Example employee asks:

“Siapa account owner Client A, kontraknya kapan renewal, dan product dependency apa?”

Internal graph can answer if user has permission.

Public AI should not.

Same entity, different access context.

Agentic era makes boundary even more important.

Companies will have:

Public machine-readable surface.

Partner authenticated surface.

Internal employee surface.

Maybe regulator surface.

One graph can project multiple views.

Governance becomes architecture.

Public Graph Tidak Harus Mengungkap Semua Ownership

Sometimes corporate relationship is public by law/announcement.

Sometimes private subsidiary details confidential.

Follow legal/public disclosure requirements.

Do not use entity strategy to force disclosure.

If relationship is already public and important for disambiguation, represent it accurately.

If not public, don't fabricate or leak.

GEO is not corporate intelligence operation.

Public Evidence Layer

Public graph can link entity to evidence.

Company → research.

Product → documentation.

Person → authored article.

Claim → case study.

But evidence itself must be public.

Internal confidential case study cannot become public edge just because it proves competence internally.

Maybe create anonymized public evidence with permission.

Separate proof layers.

Trust strategy must respect contracts.

Example: Client Relationship

Internal graph:
Client A → contractedWith → Agency B.

Public graph:
Only if both sides have publicly announced/authorized case study.

Otherwise no.

This is common risk.

Sales CRM knows everything.

Marketing cannot publish everything.

Graph automation must have publication status.

Field:

public_visibility:
public / restricted / private.

Without this, accidental disclosure is waiting to happen.

Audit Public Projection

For each public entity:

What fields exposed?

Why?

Evidence?

Owner?

Last reviewed?

Privacy check?

Legal check if needed?

Schema mapping?

Visible content?

Canonical URL?

Then compare internal truth.

Public page may lag.

Flag.

Automation can generate review queue.

Do not auto-publish sensitive change.

Human approval.

Internal Graph Bisa Berisi Contradiction, Public Graph Seharusnya Tidak

Large organizations have messy systems.

CRM says office A.

ERP says office B.

HR says legal entity C.

Internal graph can surface conflict.

Public publisher must resolve before exposing.

A knowledge graph isn't just merger.

It can detect inconsistency.

Use SHACL or custom validation internally if sophisticated.

Or simple rules:

One current CEO.

One canonical official domain.

No product without owner.

No branch without parent.

No public claim without evidence.

Then publish clean projection.

Graph Governance Lebih Penting daripada Graph Database

Neo4j.

RDF store.

Postgres.

GraphQL.

JSON.

Spreadsheet.

Technology secondary.

If team doesn't know:

Who owns entity?

Who approves relation?

How to update?

What is public?

What is private?

How to retire?

How to source?

Then fancy graph database won't save project.

Internal/public distinction is governance first.

Use tool that fits scale.

When Should Website Have Public Entity Graph?

When relationships matter.

Multi-brand.

Multi-product.

Group company.

Research organization.

University.

Publisher with authors.

Marketplace.

Franchise.

Multi-location.

Complex services.

If one small business has one brand, one location, one product, public graph can be simple.

About + product + contact + correct schema enough.

Don't build infrastructure for ego.

Human Reader Tetap Final Gate

Public graph must improve human experience.

Can visitor understand:

Who owns what?

Who wrote this?

Where is this service?

Which product is current?

Which company is official?

What evidence supports claim?

If graph only helps machine but confuses people, redesign.

Human-readable truth is primary.

Machine-readable representation follows.

AI era doesn't change that.

Dua Graph, Satu Reality, Beda Projection

Internal knowledge graph is the organization's operational map.

Public knowledge graph is the curated public map.

Internal can be deep.

Public must be safe.

Internal can include uncertainty.

Public must distinguish verified fact.

Internal can expose confidential relationships under ACL.

Public cannot.

Internal can use arbitrary ontology.

Public structured data should use standards correctly.

They should share governance where useful, not be identical.

So when someone says:

“Publish internal graph biar AI ngerti.”

The answer is not “yes” or “no”.

The answer is:

“Which entities and relationships are intended to be public, verified, useful, and safe?”

Only that subset should cross the boundary.

Good knowledge architecture isn't about telling the internet everything the company knows.

It's about telling the internet the right things, correctly.