Startup, Large Companies & Entrepreneurship

Contents

• Stakes (Extrapolating)
• Place in the 2-year path
• Industry and research links
• A worked case: the graph+text demo
• How to approach it

Stakes (Extrapolating)

Not in the LLGA 2026–2027 list. In 2026–2027 the Period 2 management units of the track are IME_52441_EP — Simulation d’entreprise, a one-day serious game in which teams of five run competing multinational phone makers (R&D, plant sizing, pricing, accounting, responsible-sourcing trade-offs), and IME_52470_EP — Digital Transformation and AI in Organisations and Society (Daniel Curto), on how AI systems reshape organisations, work and decision-making once they leave the lab (group project and individual exam).

The startup/entrepreneurship pair below comes from the earlier wiki curriculum and is kept as background. Extrapolated notes. Brochure title: Startup and Large Companies: Building a Bridge for Innovation or Entrepreneurship for Sustainability / Case Studies on Innovation. Shared thread: how an innovation (often technical) crosses the startup ↔︎ large-company boundary under governance, risk, and sometimes sustainability constraints.

In the wiki curriculum, the pair followed P1 strategy/marketing with cases: alliances, scaling, and friction between startup speed and corporate process — very visible when industrializing an AI model. The official case material is not reproduced here; one illustrative case shows the reasoning on a Period 2 demo.

Place in the 2-year path

Upstream: Strategy / Marketing. Here (P2 in the wiki curriculum): applied innovation during the RL / Graph ML / NLP core; in 2026–2027 the Period 2 management slot is held by IME_52441_EP and IME_52470_EP. Downstream: P3 research internship, then M2 transverse project + final internship.

Industry and research links

Industry: intrapreneurship, corporate venture, tech transfer, AI product ops. Research: result maturity (TRL), IP, open-source vs proprietary — recurring in lab internships and CIFRE.

A worked case: the graph+text demo

Illustrative An invented scenario, with no real company behind it. It applies the bridge questions of How to approach it to one Period 2 deliverable.

The demo. A student team has built the question-answering system of capstone Y1.1: text becomes a knowledge graph (NLP), a retriever walks the graph (Graph ML), a bandit learns which retrieval mode is worth its token cost (RL), and an LLM writes the answer with its sources. A mid-size industrial company wants it for its maintenance manuals. One team member would rather found a startup around it.

Step 1 — Who pays, who uses, who operates.

• The payer is the head of maintenance, who owns the budget and must see fewer hours lost searching manuals.
• The users are about 300 technicians, often on a tablet in a workshop.
• The operator is the company’s IT team on the corporate route, or the startup on the spin-off route. Whoever operates also answers the call when an answer is wrong.

Step 2 — Maturity. On the technology readiness level (TRL) scale, the demo is at TRL 4: validated in the lab, on a public proxy corpus. Run on the company’s own manuals, it reaches TRL 5–6 (validated, then demonstrated, in a relevant environment). A pilot used by technicians in the workshop is TRL 7. The gap is work the demo skipped: per-document access rights, refreshing the graph when a manual changes, and a test set written with technicians.

Step 3 — Risk register.

• Data: confidential manuals leave the company network if the LLM is a remote API. Mitigation: a contract with no data retention, or a self-hosted open-weights model.
• Wrong answers: an invented torque value can damage a machine. Mitigation: answer only from a cited passage, and abstain otherwise.
• Dependency: the whole product rests on one model provider and one licence. Mitigation: keep a second model that passes the same tests, and check that the model licence allows commercial use.

Step 4 — Two routes.

Step 5 — Cost check. Take requests the size of the worked example in MLOps ch. 4, a Year 2 course: 1,500 tokens in and 300 out, at its illustrative API prices.

• Volume: 300 technicians × 10 questions per working day × 20 working days give about 60,000 requests a month.
• API bill: 0.0027 € per request, so 60,000 × 0.0027 € ≈ 160 € a month.
• Own model: that example’s break-even volumes are about 185,000 requests a month (distilled 1B student) and 580,000 (fine-tuned 8B), three to ten times this volume.
• Verdict: price favours the API. A case for self-hosting has to come from the data constraint of Step 3.

What the case teaches. The model was the easy part. The bridge is decided by who signs the run budget after the pilot, who answers for a wrong answer, and whether the data may leave the building.

How to approach it

• Take a P2 technical deliverable (e.g. the graph+text demo of capstone Y1.1 or Y1.3) and write the startup/corporate “bridge”: who pays, who operates, what risk. The worked case shows the five steps.
• For the cost argument, compute the cost per request and the break-even volume between an API and your own model with MLOps ch. 4 (Year 2; Proposition 4.2 gives the break-even volume).
• If the sustainability option is chosen, cross-link with Optimization for AI (APM_52067_EP, Period 2; ch. 10 on training networks) and Optimization and Responsible AI for Sustainability, whose ch. 6 measures the energy and carbon footprint and whose ch. 3 gives the frugality levers.
• The responsible-AI module is no longer a Period 2 companion: in 2026–2027 it is taught in Period 1 as CSC_51076_EP and is not in the LLGA lists.

Extrapolating Framing support; the case above is illustrative, and official cases and grading belong to the course units actually taught (in 2026–2027, IME_52441_EP and IME_52470_EP).