---
title: "ING-B: AI for electrical engineering documents"
canonical: https://wavect.io/blog/ing-b-ai-electrical-engineering-opportunities/
language: en
description: "Independent ING-B analysis of AI for electrical engineering documents: tender revisions, lighting evidence and handover checks, with a synthetic review example."
image: "https://wavect.io/img/blog/headers/header_ing-b-ai-electrical-engineering-opportunities.png"
author: ["Kevin Riedl"]
published: "2026-11-07"
updated: "2026-11-07"
reviewed: "2026-11-07"
---

# ING-B: AI for electrical engineering document review

[**Back**](/blog/overview/)

[![Kevin Riedl](/img/team/kevin.webp)](/team/kevin-riedl/)

[Kevin Riedl](/team/kevin-riedl/) https://linkedin.com/in/wsdt

9 min read · 7 Nov 2026 Last reviewed November 7, 2026

[**Next**](/blog/ai-pilot-kill-or-scale-scorecard/)

TL;DR

ING-B's published electrical-engineering services suggest a bounded AI experiment: prepare a source-linked requirements and revision register for an engineer to review. We would test quantity changes, omitted requirements and uncertain room identities before considering lighting-product evidence or handover-document checks. These are independent proposals, not reported company implementations. Keep original passages, document revisions and unresolved questions visible. Measure total preparation, review and correction effort, and leave design, commissioning and release decisions with responsible specialists.

Independent analysis

Wavect has not been engaged by, and is not affiliated with or endorsed by, ING-B. This article is an independent, outside-in analysis based exclusively on publicly available information. Proposed solutions, architectures and potential impacts are hypothetical and illustrate approaches we would investigate if working on comparable challenges. They are not claims about ING-B's internal systems. [office@wavect.io](mailto:office@wavect.io)

**A revised electrical specification needs a checked record of what changed.** For an independent ING-B AI opportunity analysis, we would first test a source-linked requirements and revision register. An engineer would resolve ambiguous changes against the original passages, then decide what enters issued documents. The value of that experiment still needs measurement.

**Public sources checked: 7 November 2026.** This research used published service descriptions and technical guidance. We had no access to ING-B project files or staff interviews. No AI system was tested. The proposed workflows describe experiments we would investigate in comparable work, without asserting an internal need or a missing capability at ING-B.

## Where could ING-B use AI for electrical engineering document review?

**ING-B's published services make tender review, lighting evidence and handover documentation concrete subjects for an AI experiment.** Its [service overview](https://www.ing-b.at/leistungen/) covers tender preparation and bid review alongside site supervision. That identifies document families to investigate; it does not establish how the company manages them internally or whether assistance would save time.

The [ING-B FAQ](https://www.ing-b.at/faq/) lists tender specifications, installation and wiring plans, and invoice review. It also describes Dialux lighting calculations, DALI/KNX integration and BIM planning on request. Those statements do not establish which project-file formats or integrations a pilot could access.

The [public brochure's service list, printed pages 04-05](https://www.ing-b.at/wp-content/uploads/2024/10/ING-B-Hauptfolder.pdf) also covers calculation and documentation. A draft finding should retain its source and review decision.

| Proposed experiment | Reviewable output | Condition for choosing it |
| --- | --- | --- |
| Requirements and revision review | Changed passages with document versions and open questions | A specialist can define the expected findings |
| Lighting-product evidence comparison | Exact product variant, stated value, unit and source | An approved brief and applicable manufacturer documents exist |
| Handover evidence check | Missing, mismatched or unresolved documentation | The project has an agreed delivery checklist |

## Which AI opportunity would we test first?

**We would start the ING-B example with a requirements and revision register.** A revision register is a table that records each changed requirement with its source versions and review decision. For a fixed document pair, an engineer can record the expected findings before evaluating the assistant's draft.

Choose one document family and one reviewer. Fix the revision pair and the sections in scope. Ask the assistant to collect candidate differences. Compare extracted quantities and identifiers with ordinary code, preserving their units. Keep the original passages beside each finding.

Export the review table without write access to issued documents or live equipment. Consider integration after measuring the value of that output.

## What should a revision register catch?

**For the ING-B experiment, a revision register should separate changed values, omitted requirements and uncertain identities.** Every identifier and product label in the following fixture was invented for the example. It is a proposed acceptance example, not ING-B project data or electrical-design advice. No AI system was run against it for this article.

**Revision A, section 2.4:** Room R-204: supply 12 luminaires of type L-07. Connect them to control group C-3.

**Revision B, section 2.4:** Room R-240: supply 16 luminaires of type L-07.

| Observed difference | Expected draft finding | Decision still needed |
| --- | --- | --- |
| 12 becomes 16 luminaires | Quantity changes by 4, preserving both passages | Engineer confirms the intended quantity and scope |
| Control group C-3 is omitted | The earlier control requirement remains visible as an unresolved deletion | Engineer confirms whether its removal is approved |
| R-204 becomes R-240 | Room identity is uncertain | Reviewer checks the approved room mapping |

The quantity arithmetic is 16 − 12 = 4. That does not prove the two passages concern the same room. An assistant that reports only the count has missed a separate review question. It must preserve the identity ambiguity until someone resolves it.

Preserve each passage's filename, revision and section. Store the draft finding separately from the reviewer's decision. If text extraction cannot read a page, the register must show an incomplete comparison. An empty finding list cannot stand in for a completed check.

## How could AI support lighting-document review?

**For lighting-document review, we would test an evidence table tied to exact product variants and an approved brief.** [ING-B's lighting-planning page](https://www.ing-b.at/lichtplanung/) describes calculation, simulation, technology selection and technical documentation. An assistant could prepare candidate evidence for those decisions, while a qualified reviewer checks applicability and performs the necessary engineering work.

Each row needs the exact product code and supporting passage. Retain the original unit and any qualifying footnote. A value for a similar luminaire must not fill a gap in the selected variant's evidence. Mark the missing value and ask for the applicable document.

The engineer retains responsibility for lighting calculations, suitability assessment and design approval.

## What could a handover evidence check prove?

**A handover evidence check can organize documents against agreed requirements, but it cannot establish that physical testing occurred.** [ING-B's building-management services](https://www.ing-b.at/gebaeudeleittechnik/) include technical documentation and commissioning support. A proposed assistant could collect candidate records and flag gaps for review, keeping document completeness separate from the specialist's acceptance of actual results.

Use the project's approved delivery checklist. As a separate Austrian public example, [BIG's documentation requirements](https://www.big.at/projekte/dokumentation) address room and asset identifiers, document naming and storage, and say the required scope must be agreed for the specific project. We have not verified a particular ING-B assignment or its applicable requirements.

| Field | What the reviewer needs |
| --- | --- |
| Requirement | The agreed checklist item and its source |
| Identity | Equipment or room identifier, document revision and location |
| Evidence state | Present, missing, conflicting or unreadable |
| Result and acceptance | Observed result, responsible reviewer and recorded decision |

Test a fictional row where a commissioning instruction is present but the observed-result field is blank. The expected output is a missing-result flag. The assistant must not turn an instruction into a successful test or copy an outcome from another equipment identifier.

## Where does BIM information checking fit?

**For the ING-B example, BIM information checking is a later option with suitable model data and approved information requirements.** The [buildingSMART IDS user manual](https://github.com/buildingSMART/IDS/blob/development/Documentation/UserManual/README.md) describes specifying and checking simple information requirements from IFC models. That supports a narrow information-checking experiment; it does not establish which exports or validators ING-B uses.

An engineer could approve the information requirements, run a dedicated checker against a specified IFC revision and ask AI to explain its issue list. Attach each explanation to the element identifier and original rule result. Keep overall engineering validation separate. This information check does not establish collision freedom or a successful commissioning result.

If the proposed review later needs a connected retrieval application, the [production RAG readiness checklist](/blog/rag-production-readiness-checklist-eu/) addresses that broader implementation decision.

## How should the first experiment be evaluated?

**Evaluate the proposed ING-B document-review experiment against expected findings and the work left for the engineer.** [NIST's Generative AI Profile](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf) recommends checking generated sources and citations and avoiding performance extrapolation from narrow assessments. For this pilot, retain the original evidence. Reserve examples that were not used to refine prompts.

1. Have a specialist record the expected findings before running the proposed test.
2. Include the fictional quantity, deletion, identity and missing-result cases, plus unchanged documents to expose false flags.
3. Try unreadable pages and conflicting revisions. Require the output to identify the gap.
4. Check every claimed source passage and record omitted findings and incorrect flags.
5. Measure all human work through to acceptance, including corrections and failed attempts.

An invented requirement fails the test. So does silently resolving a room mismatch or asserting a result without evidence. A clean small test leaves future reliability unproven. Before using representative nonpublic files, agree access and processing with their owner.

## When would the business case justify another step?

**The business case improves only if assisted review reaches an accepted result with less total work at the required quality.** Compare similar tasks, including preparation and corrections. Keep model waiting separate unless it occupies the reviewer. Include implementation and ongoing software costs. Document upkeep and repeated evaluation also consume the capacity the business case is meant to release.

**Net human time saved per comparable task = manual human time − all human time in the assisted workflow.** Measure task volume before scaling that figure. ING-B's actual handling effort is unknown, so we give no savings or payback estimate.

The [AI pilot kill-or-scale scorecard](/blog/ai-pilot-kill-or-scale-scorecard/) covers the later operating decision. The [internal AI assistant cost guide](/blog/internal-ai-assistant-cost-dach/) helps identify budget categories after the source scope and deployment requirements are known.

## What would a useful first brief contain?

**For the ING-B example, specify the evidence a reviewer needs to accept one defined output.** Choose the revision pair and agree the rejection cases before comparing manual with assisted review. Require less total effort per accepted review before expanding.

Use the [AI automation project brief](/software-development-guide/ai-automation-project-brief/) to record the acceptance conditions and review responsibility. Agree usable exports. The separately published [Twinsoft AI case study](/case-studies/twinsoft-ai/) provides adjacent delivery context; it does not establish an ING-B implementation.

Our [technology consulting service](/services/technology-consulting/) can turn a bounded build-or-buy question into a written recommendation. [Scope one review task with the person who approves the result](/contact/?intent=technology-consulting).

## ING-B AI opportunity questions

### Is this an ING-B customer case study?

No. ING-B has not engaged Wavect for this analysis, and there is no affiliation or endorsement. The article develops independent proposals from published service information. It reports neither an internal problem nor a company AI implementation. No measured saving or ING-B project outcome is claimed. Each proposal would need its own evaluation.

### Can the first test use only public or fictional documents?

Yes. Public documents and clearly fictional revisions can test whether a draft traces requirements correctly. They can also expose missed deletions or uncertain identity mappings. That does not establish value for a company's actual workload. A later authorized pilot needs representative permitted inputs and a responsible reviewer who can provide the manual baseline.

### Would the assistant need to connect to live building controls?

The proposed first experiment needs read-only review material and an exported register. It does not require live KNX or DALI actions, edits to issued drawings or invoice writes. Any later integration would be a separate decision with its own authorization, technical checks and operating responsibility.

### Does the pilot need model training?

We would first evaluate an existing model against an approved source set. Require structured outputs and ordinary checks for extracted values, with explicit handling of units. Consider training only after diagnosing a specific gap that simpler changes cannot resolve. Training alone does not keep revised project documents current or approve their contents.

### What happens when a file is unreadable or an identifier is ambiguous?

Mark the extraction or mapping as unresolved and preserve the affected source location. Ask for a readable document or an approved identity mapping. The register should show that the comparison is incomplete. A plausible guess or an empty issue list must not be presented as a completed review.

### Who should own the pilot's documents and test set?

Agree ownership and usable exports for the pilot artifacts in the project brief. Include the source register and test fixtures, with expected answers beside the evaluation records. Record model and parser versions, prompts and extraction settings so the evaluation can be reproduced. Name the person responsible for document changes, access and unresolved findings after the pilot.

Architecture and platforms

## Read next

Framework, platform and system-design choices that affect delivery over the long term.

[Start here**Smart City Architecture Best Practices: MQTT, LoRaWAN, Kubernetes and Terraform**](/blog/smart-city-architecture-best-practices-2026/)

- [img2threejs: Turn an image into editable Three.js code](/blog/img2threejs-image-to-editable-3d/)
- [Organoid: AI material specification with evidence attached](/blog/organoid-ai-material-specification-opportunities/)
- [Odoo + n8n: retry order creation without duplicates](/blog/odoo-n8n-idempotency-recovery/)
- [HubSpot and Odoo: who may change customer data?](/blog/hubspot-odoo-customer-data-ownership/)
- [Odoo email and PDF quotations: review products and prices first](/blog/odoo-email-pdf-quotation-review/)

[Previous article**Organoid: AI material specification with evidence attached**](/blog/organoid-ai-material-specification-opportunities/) [Next article**Odoo + n8n: retry order creation without duplicates**](/blog/odoo-n8n-idempotency-recovery/)

[**Back**](/blog/overview/)

[![Kevin Riedl](/img/team/kevin.webp)](/team/kevin-riedl/)

[Kevin Riedl](/team/kevin-riedl/) https://linkedin.com/in/wsdt

9 min read · 7 Nov 2026 Last reviewed November 7, 2026

[**Next**](/blog/ai-pilot-kill-or-scale-scorecard/)