# AI for IFS Cloud in aerospace and defense manufacturing

> Source: https://netray.co/erp-ai/ifs-cloud-aerospace-defense-ai
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: AI for ERP

## Short answer

IFS Cloud programmes in aerospace and defense sit on IFS's projection layer (OData-based) and Aurena UI, with heavy use of project-based manufacturing, configuration management, and document control. A private LLM grounded on those projections, run on infrastructure the programme controls, gives engineers and planners natural-language answers without exporting export-controlled or classified-adjacent data to a multi-tenant AI service.

## Kind

platform

## Erp Family

ifs

## Erp Products

- IFS Cloud
- IFS Applications 10

## Industries

- Aerospace
- Defense
- MRO

## Region

Global

## Persona

CIO

## Eyebrow

IFS Cloud + on-prem AI

## Intro

If your IFS Cloud instance runs a defense programme or an aerospace supply contract, the questions you get from planners and engineers are rarely one-click answers inside Aurena. "Which work orders are behind on this project because of a late-arriving part" or "what configuration changes touched this serial number" require joining project, manufacturing, and document data that IFS presents as separate lobbies and pages.

IFS.ai, IFS's own generative AI layer, is improving quickly, but for programmes carrying ITAR technical data, CUI, or a foreign military sales condition, the question is not whether the built-in assistant is capable, it is whether the underlying model call, telemetry, and any cached context stay inside your compliance boundary. Many A&D IFS shops cannot answer that question with certainty for a vendor-hosted feature, which is what pushes them toward a self-hosted option.

IFS Cloud's architecture actually helps here: everything is exposed through typed OData projections, the same interface Aurena itself uses, so a private AI layer can read the identical data model without touching the database directly or maintaining a shadow copy of business logic. That symmetry is unusual among ERPs and worth building on rather than working around.

This page describes what an on-prem or private-cloud AI layer over IFS Cloud looks like in practice for aerospace and defense programmes: what to connect to, what to keep read-only, and where a private LLM earns its keep against project managers, planners, quality engineers, and configuration management staff.

## Pain Points

### Programme status buried across lobbies

**Detail:** Project managers piece together programme health from separate IFS lobbies for project, manufacturing, and procurement rather than one grounded answer that cites the underlying projections.

### Configuration management questions take specialist time

**Detail:** "What changed on this serial number and when" requires someone who knows the Config Management module and its link to the engineering structure; that knowledge is concentrated in a small team.

### Export-controlled and CUI data limits which AI tools are usable

**Detail:** Engineering documents, technical data packages, and configuration records often carry ITAR or CUI markings, which rules out sending them to a public AI API for search or summarisation.

### Document-heavy compliance work is manual

**Detail:** AS9100 audits, first article inspection packages, and customer source inspection prep involve pulling documents and records from IFS Document Management by hand.

### IFS.ai roadmap uncertainty for regulated programmes

**Detail:** Programme offices want AI value now but are wary of committing workflow to a vendor-hosted assistant whose data handling for classified-adjacent or export-controlled content is still maturing.

## Use Cases

### Programme status Q&A across project and manufacturing

**Description:** A natural-language layer over the Project, Manufacturing, and Procurement projections lets a programme manager ask for schedule risk in plain English and get an answer that cites the shop order, purchase requisition, or milestone behind it.

**Erp Objects:** Project projection, Shop Order, Purchase Requisition, Activity, Milestone

**Outcome:** cuts the weekly programme status prep from a half-day of screen-hopping to a first draft in minutes, reviewed by the PM before it goes out

### Configuration management change history

**Description:** An agent grounded in Config Management and Engineering Structure data answers "what changed on serial number X and under what change order" with citations back to the change record, useful for customer audits and as-built reconciliation.

**Erp Objects:** Config Management, Engineering Structure, Change Order, Serial Structure

**Outcome:** reduces the time to assemble an as-built history for a single unit from hours of manual structure comparison to a reviewed summary

### AS9100 and first article documentation assembly

**Description:** Retrieval over Document Management and Quality projections drafts the document index for an FAI (AS9102) package or a customer source inspection, flagging any missing or superseded documents for a human to resolve.

**Erp Objects:** Document Management, Quality Inspection, FAI record, Non-Conformance

**Outcome:** shortens FAI package assembly by finding and cross-checking documents automatically, with the quality engineer confirming completeness

### Purchase order and subcontractor follow-up drafting

**Description:** For long-lead and single-source aerospace parts, an agent drafts the follow-up email or portal message for late purchase orders, with the buyer approving before it sends.

**Erp Objects:** Purchase Order, Purchase Order Line, Supplier, Requisition

**Outcome:** keeps routine expedite messages moving without buyer time on every line, freeing buyers for the exceptions that need judgment

### Non-conformance and CAPA narrative drafting

**Description:** Given a non-conformance record, an agent drafts the root-cause section and CAPA narrative from linked inspection and process data, which the quality engineer edits and signs off.

**Erp Objects:** Non-Conformance, Quality Inspection, CAPA, Process Instruction

**Outcome:** reduces the drafting time for routine NCR write-ups so quality engineers spend more of the review on the analysis, less on the prose

### Inventory and kit shortage explanation

**Description:** An agent explains why a kit is short for a shop order, tracing back through inventory, purchase order, and BOM data to the specific missing component and its expected arrival.

**Erp Objects:** Inventory Part, Shop Order Material, Purchase Order Line, BOM

**Outcome:** gives production control a direct answer instead of a manual trace through inventory and procurement screens

### Engineer-to-order estimate support

**Description:** For proposal teams, retrieval over historical project actuals (labour hours, material cost, change order frequency by project type) supports estimating for a new engineer-to-order bid.

**Erp Objects:** Project Actuals, Activity Cost, Change Order history

**Outcome:** gives estimators a faster, evidence-based starting point pulled from comparable past projects rather than starting from a blank sheet

## Architecture

**Overview:** The layer sits beside IFS Cloud and reads through the same OData projections Aurena uses, rather than querying the database directly, so business rules and access checks are respected by construction.

**Layers:**

#### IFS connector layer

**Detail:** Calls IFS Cloud's standard OData projections (Project, Manufacturing, Procurement, Document Management, Quality, Config Management) using a service account scoped to the same permission sets a real IFS user would have.

#### Data and semantic layer

**Detail:** Maps IFS entities and lookup values (states, codes, custom fields) to a business glossary so the model understands programme-specific terms like FAI, CAPA, or long-lead item without hardcoding logic per programme.

#### Model serving layer

**Detail:** Runs an open-weight model (Llama, Qwen, or Mistral class) on vLLM or Ollama inside your network or approved private cloud, with no calls to a public model API by default.

#### Retrieval and agent layer

**Detail:** Combines structured OData retrieval with document retrieval from IFS Document Management, and constrains any agent action, such as drafting a supplier email, to a human-approved send step.

#### Governance and audit layer

**Detail:** Logs every query, the projections it touched, and the answer given, in a store your compliance team can inspect, distinct from IFS's own audit log but cross-referenceable to it.

## Deployment Options

### Air-gapped on-prem

**Fit:** Programmes with ITAR technical data, CUI, or contractual data-residency terms that rule out any external network path.

**Detail:** Model, retrieval layer, and IFS connector all run inside the programme's network, on GPU hardware you own or lease, with no outbound internet requirement for inference.

### Private or sovereign cloud

**Fit:** Organisations already running IFS Cloud in a private cloud tenancy or a sovereign region who want to keep AI inference in the same boundary.

**Detail:** The model and retrieval layer run in a VPC you control, connecting to IFS Cloud over a private network path rather than the public internet, with the same access model as on-prem.

### Hybrid

**Fit:** IFS Cloud SaaS tenants with a mix of general and export-controlled data who want AI on the non-sensitive majority now.

**Detail:** Non-sensitive projections (general procurement, non-controlled document sets) are indexed for AI use while ITAR- or CUI-tagged data stays excluded until an on-prem path is in place.

## Compliance

### Keeping model inference and any retrieval index inside the programme's own infrastructure avoids sending technical data to an external AI provider, which US export control counsel generally treats as a deemed export risk if handled incorrectly.

**Framework:** ITAR / EAR technical data

### Deploying inside the same enclave that already handles CUI in IFS Cloud means the AI layer inherits existing access control, logging, and boundary protections instead of introducing a new external data flow to assess.

**Framework:** CMMC 2.0 / NIST SP 800-171

### Every AI-assisted answer, document draft, or non-conformance narrative cites the source IFS records it drew from, so a human reviewer can verify it against the same evidence an auditor would check.

**Framework:** AS9100D traceability

### For UK MOD-facing programmes, running inference within the contractor's accredited boundary avoids introducing an unassessed third-party processing step for defense-related data.

**Framework:** UK DEFCON 658 / Cyber Essentials Plus (for UK programmes)

## Integration Notes

Connect through IFS Cloud's standard OData projections (the same ones Aurena and IFS Connect use) rather than direct database access, so upgrades to newer IFS Cloud releases do not break the integration.

Use a dedicated service account with role-based permission sets scoped to only the projections the AI layer needs, mirroring least-privilege practice for any other integration user.

For document retrieval, index IFS Document Management metadata and, where permitted, document text, respecting the same access classes and revision control IFS already enforces.

Config Management and Engineering Structure data has its own object model in IFS Cloud; map it explicitly rather than assuming it behaves like a flat BOM.

Any write-back, such as updating a non-conformance record or creating a follow-up activity, should go through the same OData projection with a human approval step before commit, never a direct table write.

Aurena's Lobby and Insight pages are a UI layer, not a data source; the AI layer should query the underlying projections directly rather than scraping rendered pages.

For multi-site or multi-company IFS Cloud instances, scope retrieval per company and site to avoid an agent answering with data from a programme the requester should not see.

## Product Fit

### ERPray

**Why:** ERPray's connector architecture is a fit for IFS Cloud's OData projection model: natural-language questions and dashboards over Project, Manufacturing, and Quality data, read-only by default, with the underlying query shown.

### Custom build

**Why:** Config Management change-history agents, FAI package assembly, and CAPA narrative drafting are programme-specific enough that most teams start with a scoped custom build before considering a packaged product.

## Engagement

### Discovery

**Duration:** 2-3 weeks

**Deliverables:**

- Inventory of IFS Cloud projections in use and their data sensitivity (ITAR, CUI, unrestricted)
- Target use cases ranked by programme value and data risk
- GPU and hosting plan sized to expected concurrent users

### Pilot

**Duration:** 6-8 weeks

**Deliverables:**

- Working connector to 2-3 priority projections (e.g. Project, Manufacturing, Document Management)
- One or two agreed use cases (status Q&A, config history, or FAI drafting) live for a pilot group
- Audit log and access-control review with your security team

### Production

**Duration:** Ongoing after pilot sign-off

**Deliverables:**

- Rollout to the full programme office or engineering team
- Expanded projection coverage (Quality, Procurement, Config Management)
- Documented runbook for model updates and access changes

### Scale

**Duration:** Following programme cycles

**Deliverables:**

- Extension to additional programmes or IFS Cloud companies
- Agent capabilities with approval-gated write-back (follow-up emails, draft NCRs)
- Periodic model and retrieval accuracy review against real usage logs

## Buyer Questions

- Where does inference actually run, and can you show the network path technical data would take end to end?
- Does the AI layer read IFS Cloud through standard OData projections, or does it require a database replica that falls out of sync?
- What happens to ITAR or CUI-marked documents if they are accidentally included in a retrieval index; can they be excluded by classification tag?
- Can every AI-generated answer be traced back to the specific IFS records it used, in a form your compliance team can review?
- What is the fallback if the model gets an answer wrong, and how is that logged and corrected?
- How does the solution handle an IFS Cloud version upgrade; does the connector need to be rebuilt?
- Who has access to the query and answer logs, and how long are they retained?
- What GPU hardware and hosting does this require, and who is responsible for keeping it patched?

## Faq

### Can AI work with IFS Cloud without exporting data to IFS.ai or another cloud service?

**Answer:** Yes. IFS Cloud's OData projection layer, the same interface Aurena uses, can be read by a self-hosted model running on your own GPUs or in your private cloud. Nothing has to leave your network, and no call needs to go to IFS.ai or any external AI provider unless you choose to use it.

### Is IFS.ai an alternative to a private LLM for aerospace and defense programmes?

**Answer:** IFS.ai is IFS's own generative AI capability and is worth evaluating for non-sensitive workflows. For technical data under ITAR, CUI, or a classified-adjacent handling requirement, most programme security teams want inference to stay inside their own accredited boundary, which points toward a self-hosted model beside IFS Cloud rather than a vendor-hosted assistant.

### How does AI handle IFS Cloud's Config Management and Engineering Structure data?

**Answer:** Config Management and Engineering Structure have their own object models distinct from a standard BOM. A grounded AI layer maps these explicitly, retrieving change orders, serial structures, and revision history through the correct projections so answers about what changed on a specific unit are accurate rather than inferred.

### What is a realistic first use case for AI on IFS Cloud in an A&D programme?

**Answer:** Programme status Q&A over Project and Manufacturing data is a common starting point: it has clear value for programme managers, touches a bounded set of projections, and does not require write access, which keeps the pilot's risk surface small.

### Does this require replacing or duplicating the IFS Cloud database?

**Answer:** No. The recommended approach reads through IFS Cloud's existing OData projections rather than replicating the database, which avoids a second copy of sensitive data to secure and keeps the AI layer consistent with IFS's own access rules.

### Can the AI layer draft documents like FAI packages or CAPA narratives, or only answer questions?

**Answer:** Both are workable. Drafting is typically scoped as a human-in-the-loop step: the model assembles a first draft from linked IFS records, and the quality engineer or programme manager reviews and finalises it before it becomes an official document.

### How long does a pilot take for AI on IFS Cloud?

**Answer:** A focused pilot on one or two use cases, such as programme status Q&A plus document retrieval, typically runs six to eight weeks after a two to three week discovery phase to map which projections and data sensitivities are in scope.

## Search terms

IFS Cloud AI, IFS Cloud AI integration, on-prem AI for IFS Cloud, IFS.ai alternative, IFS Cloud aerospace defense AI, IFS Cloud copilot, IFS Cloud generative AI, IFS Aurena AI, private LLM IFS Cloud, IFS config management AI, IFS Cloud ITAR AI, IFS Cloud OData AI agent

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json