AI in the Space Industry: secure information starts with clear AI boundaries

AI can help space engineers search requirements, analyse technical documentation, investigate anomalies and find connections across large amounts of engineering data. These capabilities can save engineers considerable time across the space project lifecycle. They also introduce questions around access, data control, reliability and engineering authority. When AI becomes part of an engineering workflow, organisations need to decide what information it can access and how engineers can rely on its output.

For space organisations, this leads to a practical question.

• What information can AI?
• What can AI do with it?
• Where does engineering authority remain?

Answering these questions gives organisations a basis for using AI while keeping engineering information and decisions within the boundaries set by their programmes.

Control what AI can see

You can give AI access to large parts of your engineering information. The more information it can search, the more context it may have when answering a question. Yet access to everything is rarely what an AI needs for a specific engineering task.

A requirements assistant may only need access to approved requirements and related technical documentation. An AI supporting an anomaly investigation may need a different information set. Giving each AI access based on its purpose keeps the information available to it focused on the task.

This leads to the first question organisations need to answer before connecting AI to engineering information: what does this AI actually need to see?

What engineering information should stay controlled?

Space programmes contain large amounts of controlled engineering information. This includes documents and records covering areas such as:

• Requirements and specifications
• Risks and risk assessments
• Non-conformances and related investigations
• Technical reviews and review evidence
• Verification evidence
• Interface information
• Test results
• Mission operations information
• Software and source code
• Security related technical information

Engineers rely on this information to understand the current state of a programme and make engineering decisions. The information therefore needs to remain reliable and secure, with its status and source clear to the people using it.

Connecting AI to this information changes who or what can process it. An AI system with access to a document repository may be able to retrieve information across many documents within seconds. Information that was previously available through controlled engineering systems can therefore become available through another processing layer.

The question is wider than whether an engineer has permission to open a document. Organisations also need to decide whether an AI system should have permission to process that document.

Why external AI requires careful information handling

Cloud based AI services such as ChatGPT, Microsoft Copilot and DeepSeek make powerful AI models readily available. Their use with engineering information requires a clear understanding of how each service handles the information provided to it.

Before engineers enter controlled information into an external AI service, the organisation needs to understand what happens to that information after it leaves its engineering environment. The answer can vary by service, account type and configuration.

Three areas deserve particular attention:

• Retention and logging.
  Prompts, uploaded documents and generated responses may be retained or recorded according to the service and its configuration. Organisations need to know where that information is stored and for how long.
• Model training and secondary use.
  Organisations need to establish whether supplied information can be used for model improvement, service improvement or another form of processing beyond the immediate request.
• Information boundaries.
  Once engineering information enters an external service, its processing takes place within infrastructure and systems outside the engineering environment that originally controlled it.

This makes clear rules for external AI valuable. Engineers need to know which information they can provide to an external AI service and which information stays within controlled engineering systems.

A human permission to read data should never become an automatic AI permission

An engineer may have broad access because their role requires it. A systems engineer, for example, may need information from several disciplines across a programme. Giving an AI tool the same access simply because it operates on behalf of that engineer creates a much larger information boundary than many AI tasks require.

A useful rule is: a human permission to read data should never automatically give their AI permission to read that data.

Instead, AI access can be defined around the task it performs. The engineer’s access provides one boundary. The AI can operate within a smaller information space based on the documents and data required for its purpose.

This gives teams two practical questions to ask whenever AI is connected to engineering information:

• What can the AI see?
• What does the AI need to see for this task?

The difference between those questions matters. Technical access may make thousands of documents available, while the engineering task may require only a selected set of controlled sources.

What should cybersecurity ask before AI gets access?

Cybersecurity teams can turn these principles into clear access rules before engineering information is connected to AI. The goal is to understand the complete path between the engineering source and the AI system, including what information crosses each boundary.

Ten questions provide a practical starting point:

1. What information will the AI be able to access?
2. Where will the information be processed?
3. Where can prompts, files and responses be stored?
4. How long can the service retain that information?
5. Can supplied information be used for model training?
6. Can access be logged and traced back to a user, task or AI system?
7. How can AI access be changed or withdrawn when the task is done?

The answers can then become concrete rules for each AI use case. One AI system may receive access to public technical documentation. Another may work with a selected set of controlled documents inside organisational infrastructure. The access boundary follows the information and the task rather than the capabilities of the AI model.

Control what AI can do

Giving AI access to engineering information is one decision. Giving it permission to act on that information is another. An AI system can simply search for information, or it can be given the ability to create content and interact with engineering systems.

These permissions have very different engineering consequences. Finding a requirement is different from rewriting it. Analysing a risk is different from changing its status. AI authority therefore needs its own boundaries.

A convincing AI answer can still be wrong

AI can produce an answer that looks technically convincing while containing incomplete reasoning, incorrect assumptions or information that does not belong in the engineering record. This becomes more important when AI moves from finding information to interpreting or changing it.

Consider what happens when AI takes a more active role in engineering work:

• Letting AI judge a risk heatmap: AI could assess probability or consequence differently from the engineering team and place a risk in the wrong category.
• Letting AI rewrite requirements: A small wording change can alter the meaning, scope or verifiability of a requirement.
• Letting AI run a technical review: AI could identify useful findings while overlooking an interface issue, missing evidence or accepting an assumption that requires engineering review.
• Letting AI assess a non conformance: Its recommendation could influence disposition or follow up actions without having the full manufacturing context.

It is easy to see what can go wrong when an AI output starts influencing controlled engineering work. AI can assist with these activities while engineering authority remains with the people responsible for the programme.

Give AI authority based on its task

The first approach is to give AI only the capabilities required for a specific task. An AI used to search requirements may only need read access. An AI preparing information for a technical review may be allowed to analyse selected documents and produce a draft outside the controlled record.

This keeps AI authority focused. The question becomes: what does the AI need to do to complete this particular task?

The permissions can then follow the answer. Search may require read access. Drafting may require a separate workspace. Changes to controlled engineering information can remain within the established engineering process.

Bring AI output into the controlled system

A second approach is to keep the AI outside the controlled engineering system. Engineers can use an external AI environment to prepare an analysis, rewrite a requirement or review information. The resulting content can then be brought into the controlled system through the established engineering process.

This creates a clear boundary. AI produces input for the engineering process rather than directly changing the controlled engineering record.

For example, AI could propose a rewritten requirement in a separate environment. An engineer reviews the proposal and compares it with the original requirement. Only the approved version then enters the requirements management system through its established change process.

This approach can be useful when organisations want access to AI capabilities while keeping direct write access to controlled engineering systems tightly restricted.

Always check what AI has done

AI generated engineering work needs engineering review before people rely on it. The level of review can follow the consequence of the task, with closer verification for outputs that influence engineering decisions.

A few practical checks can make that review more concrete:

• Check the source: Confirm that the AI used the applicable documents and correct revisions.
• Check what changed: When AI rewrites or modifies information, compare its output directly with the controlled original.
• Check what may be missing: Review the output for requirements, interfaces, evidence or dependencies that the AI may have left out.
• Record the human decision: Keep approval and engineering authority within the process and role responsible for that decision.

AI can therefore prepare engineering work while an engineer determines whether that work is suitable for use within the programme.

Match AI operations to engineering risk

The amount of authority given to AI can follow the engineering consequence of the operation. Some activities give AI very little influence over the controlled engineering record. Other activities can directly affect spacecraft configuration, verification or operations.

Lower impact AI operations can include:

• Searching approved engineering documentation
• Summarising selected documents
• Finding related requirements
• Organising information for an engineer
• Preparing a draft for review
• Comparing document revisions

Higher impact AI operations can include:

• Changing controlled requirements
• Accepting verification evidence
• Changing risk classifications
• Dispositioning non conformances
• Approving technical review findings
• Changing spacecraft configuration
• Performing safety related calculations used for decisions
• Issuing or preparing spacecraft commands for execution

The boundary can become stricter as the engineering consequence increases. AI can have more freedom where its output remains informational. Human authority and established approval processes remain central when an AI operation can affect the controlled engineering record or spacecraft.

Decide whether AI should connect to the engineering system at all

Directly connecting AI to controlled engineering systems is only one architecture. For information with higher security requirements, separating AI from the controlled environment can provide a stronger information boundary.

AI can operate in a separate environment and produce information that an engineer reviews before bringing it into the controlled system. This limits the systems the AI can reach and keeps controlled changes within established engineering workflows.

Direct connections can then be reserved for information and operations that the organisation has assessed as suitable for that architecture. Read only access to selected lower sensitivity information, for example, creates a very different security profile from giving an AI broad access across programme systems.

Before allowing AI to perform operations within an engineering environment, security teams can ask three questions:

1. What can happen if the AI performs this operation incorrectly?
2. Does the AI need a direct connection to the controlled system to complete this task?
3. What technical control prevents the AI from accessing or changing information beyond its defined authority?

These questions move the discussion beyond what an AI model is capable of doing. They help define what the organisation is actually prepared to let it do.

Build AI around a reliable engineering environment

AI operates within an engineering environment that already controls requirements, documents, quality records and engineering decisions. Introducing AI therefore involves more than selecting a model. Organisations also need to consider the systems around it, including access controls, document management, engineering workflows and cybersecurity.

The model may change over time, while the controlled engineering environment remains the reference for programme information. The aim is to fit AI around that environment and its existing controls.

Why local AI can offer greater control

Local AI can give organisations more control over where engineering information is processed. Models can operate within infrastructure controlled by the organisation, with connectivity and access configured around programme requirements.

“Local AI” can describe several architectures. A model might operate on dedicated internal infrastructure or within another controlled computing environment. The appropriate setup depends on the information and engineering use case.

Local deployment can give an organisation greater control over data location, connectivity, model versions and updates. This can fit engineering environments where controlled change and repeatability matter.

The language model remains one component of the complete environment. Document stores, retrieval systems, authentication, APIs, model servers and engineering integrations determine how information reaches the model and what happens with its output.

For that reason, local AI and controlled AI are related, yet separate architectural questions. Where the model runs matters. What the model can access and do matters just as much.

How ECLIPSE Software Suite supports controlled engineering information

ECLIPSE Software Suite does not currently provide an AI assistant. Its role is different. ECLIPSE provides a secure and reliable environment for engineering information and structured engineering processes across the space project lifecycle.

ECLIPSE solutions support areas such as document management, quality processes and risk management. These systems help engineering teams work with controlled information while maintaining the processes around that information.

That foundation becomes relevant as organisations explore AI. AI may help engineers search, analyse or prepare information, while ECLIPSE continues to provide the controlled engineering environment in which programme information and processes are managed.

The distinction is important. ECLIPSE does not need to make an AI generated answer authoritative. Engineers can assess AI generated information and decide what belongs within their established engineering process.

This creates a clear relationship between the technologies. AI can support the engineer. ECLIPSE can support the controlled engineering information and processes. The engineer retains engineering authority.

Using external AI alongside your engineering environment

Space organisations can also use external AI services alongside their existing engineering systems. This gives teams access to current AI capabilities while allowing them to define clear information boundaries.

The starting point is knowing which information is suitable for the external environment. Public or approved information can support one group of use cases. Controlled engineering information can remain within the systems responsible for managing it.

Generated content can then return to the engineering environment when appropriate. An engineer can review the content against controlled sources before using it within a formal engineering process.

This approach makes the engineering environment the stable reference point. AI services can evolve, models can change and new capabilities can appear. Controlled engineering information remains connected with the systems and processes designed to manage it.

Keep engineers in charge with ECLIPSE Software Suite

AI in the space industry can give engineers faster ways to search technical information, connect engineering evidence and prepare analyses. Local AI can offer greater control over where that processing occurs. External AI can provide useful capabilities for information that an organisation has approved for that environment.

In each case, the same architecture principles apply. Give AI access according to its purpose. Keep controlled sources available to engineers. Match AI authority with the engineering consequence of the task. Use established engineering processes to govern what becomes part of the programme record.

ECLIPSE Software Suite provides the secure and reliable engineering environment around those processes. It gives space engineering teams a place to manage controlled information and structured workflows while they decide how AI fits within their wider technology landscape.

If your organisation is exploring AI for space engineering, start with a real engineering use case. Identify the information involved. Define what the AI needs to access and what belongs within its authority. Then connect those boundaries with the systems that already manage your engineering information.

Explore ECLIPSE Software Suite solutions to see how a secure and reliable engineering environment can support your engineering information, and contact us to get a free demonstration.